SOAP Vs. REST

Improving Testability

This is the slides for the presentation I did on the topic of writing clean, testable code. (Click on "Open in new window" icon next to the slide number for a bigger view)

10 Things Every Software Architect Should Know

O'Reilly Webcast by the author of 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

1. People are the platform
2. All solutions are obsolete
3. Data is forever
4. Flexibility breeds complexity
5. Nothing works as expected
6. Documentation is the universal source code
7. Know the business
8. Maintain the vision
9. Software architects should also be coders
10. There is no substitute for experience

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