On test coverage

Great post from google Testing:

Code coverage goal: 80% and no less!

Agility in daily life

Several years ago, when I was first introduced to Agile software development methodology, I dismissed the idea saying that its just a temporal hype. Few years later, I re-considered it because I saw it staying in the trend. I failed to see its value until I tried it myself, and when I did I was hooked. I was not only hooked, it revolutionized my life as a software developer. First time in my life, I started enjoying my trade and it boosted my confidence on the reliability of the software I write. The term 'craftsmanship' really started sinking in.

Today, I find myself not only following agile principles at work, but implementing some agility in my personal projects. Recently I experimented it with some backyard gardening.

In Summer, I usually do a vegetable garden in my backyard and every year I do it in a 'waterfall' style which involves step by step progress (building of layers) towards the goal. My goal is very simple: plant different types of vegetable seeds.

These were some steps I took to reach my goal:

Clean the previous year's residues and remove weeds from the the entire area - > Cutting the branches from the surrounding trees to allow sun exposure -> Plow the soil in the entire area -> Make multiple small hills for different types of plants - > Plant the seeds. Let's say each step (layer) took one day to complete, which means I take 5 days to reach my goal.

What is the problem with this approach?

1. Instead of building 'features', I was building 'layers' for 4 days.

2. A feeling of overwhelming before the beginning of each day's work.

3. A lack of job satisfaction at the end of each day (except the last day when I actually plant the seed)

4. High risk (At the end of step #4, If I decided to scrap my project, my 4 days of work goes waste)

This year I decided to apply small iterative steps. Instead of doing one step on a particular day, I did one small but complete iteration in one day. I cleaned a small area, I cut the tree branches required to light only that area, I plowed only that small area and planted one type of seeds and watered them. At the end of that one iteration,which I completed in one day,I felt satisfied. I produced "business value".

We have a sense of achievement and job satisfaction when we produce a working solution. But it required a change of mind-set, it required breaking a huge use case into reasonable stories (e.g: Story#1 - Plant 10 pumpkin seeds). It required building 'features', instead of 'layers'. And it is the features what produces "business value".

On domain-driven design...

One of the design principles (of any enterprise application) which I found difficult to make up my mind is: (Anemic domain models + Service Objects) Vs. Fully featured domain objects.

Most of my business (application) layer consists of many Service objects (DAOs, Session Beans, BOs, Delegates, Facades etc) AND many POJO domain objects. Here the domain objects are nothing but data holders. There is no business logic in it. Arguably, this is an application of "separation of concerns", where business and/or data access logic is separated from data holders (in other words, Transfer Objects or Value Objects).

Whereas, there is a counter argument from another side (mostly the proponents of Domain- Driven Development (DDD)) that separating domain objects from its operations is nothing but going back to procedural style of programming. I don't know if I necessarily agree with it. Frameworks like Hibernate (even JPA) allows us to embed custom SQL's inside the domain model. In my mind that is a 'mixing' of concerns. Also, imagine a method called sell() inside a Book object. Does a book know how to sell it? Also, Book has an existence without a sell()functionality. In cases like this, I prefer a BookServiceImpl.sell(book) andBookServiceImpl.calculatePrice(book) rather than Book.sell() and Book.calculatePrice().

This is not to totally dismiss the other argument. If we are developing software for a rapidly changing business domain, from a maintainability perspective, DDD approach may sound attractive. For example, when the way they sell book changes , the place it requires the code change is the Book.sell() method, where as, if we are to change the service method, it might affect various other sub-systems. But when Book object requires another domain object (e.g: CreditCard object) to do its selling, things become complicated. Yes, we can inject CreditCard object to Book object, but effectively we are introducing a level of coupling.

Craftsmanship

Craftsmanship. A term which was rarely used in connection with software development. Lately, in the Agile world, I hear this term often and it already started to shift my paradigm on many things.

It was discouraging to find out a related manifesto was already in place. This is what the manifesto says:

Not only working software,

but also well-crafted software

Not only responding to change,

but also steadily adding value

Not only individuals and interactions,

but also a community of professionals

Not only customer collaboration,

but also productive partnerships

Orthogonality

What is Orthogonality? (Thanks to Andrew Hunt and David Thomas for coining this term in connection with Programming)

When we move parallel to X-axis, no change on Y-axis. In other words, the two lines are independent. In software development, or computing in general, this can be called decoupling. I should be able to change one thing without affecting the other thing.

For example, I should be able to change the UI without having to change the database; or I should be able to change one concrete class without having to change another concrete class.

The 'Big Picture'

When I lose the 'Big Picture', I lose my vision. I have been reading 'The Pragmatic Programmer' (a great book, by the way) and there is a quote in the book which struck me:

We who cut mere stones must always be envisioning cathedrals (Quarry workers creed).

A programmer, who is working on a particular project, is doing the quarry worker's job. If we don't cut the stones by keeping the cathedral (the big picture) in mind, we will have to do a lot of patch work, rework and maintenance later on.

The construction of software should be an engineering discipline. However, this doesn't preclude individual craftsmanship...

hmm...

In the beginning...

Ok, first things first. There is nothing written on stones here. No solutions offered here. This is more of my own ramblings on things pertaining to software design, development, testing and architecture. Everything is open for discussions. After all, this is part of my own learning process...