TDD and CI - An Analogy

More often unit tests are considered to be time consumers, lines of code that add no real value to the core working of the system. Business Requirements have a first class place in the project as well as the "real" code but unit tests do not get such a place as often as they deserve.

Lately in my work I have to do lot of convincing and mentoring developers on TDD & CI and encourage them to write more unit tests. To convince and to justify the need for TDD and more unit tests and CI I came up with this analogy.

In my analogy consider the lines of "real" code that do business logic or UI logic or data access logic as the people in society. As there are good and bad elements of the society so are good and bad code modules and lines of code. As people we tend to take different roles and actions in day to day life. We drive, we go out to eat, we take a walk in park, we shop. So do these lines of code in the system take different contexts. The same method in a DAO or Service class may be used by a Web frontend or by a batch job. Some of the domain objects may be used by the UI in a certain way and persisted in database or other remote stores.

Now lets talk about the business requirements. To keep people behave well and in sanity laws are formed. Some are explicit - such as the driving laws and some are implicit - well, we don't toss burgers in a restaurants, its bad manners. The business requirements for a system are such laws that the code needs to adhere to. The code must satisfy the requirements.

Here is the fun part - In the society we have cops and agents that enforce these laws on the society. What do we have in software applications that enforce these requirements? This is where TDD, CI and even BDD comes in. It enforces that our code behaves well. If a line of code breaks a unit test it means it violated the law (the business requirements) in some way and this line of code must of brought to justice. Without unit tests we can only assume that the lines of code will behave, but what happens when a change in requirement comes up and we change the code without enforcing the new and old laws?

There can be an argument that functional testing is a good way to enforce the requirements. This can be true to a certain extent. The part of this that worries me are two things. One is that functional testing is performed at specific milestones in the project cycle. The lines of code live on after this milestone has passed and often times these lines of code change without anymore functional testing. Will it help if the cops come in a city only once a month and assumes that things are well in the city rest of the days? The second trouble is that it is not guaranteed that functional testing will cover all lines of code. Well good functional tests would at some point cover lines of code but where is the metric?

The point to be taken here is that write unit tests - these are the cops of your code. If some other developer comes and changes these lines of code and unknowingly causes them to be bad elements of the software society the cops (unit tests) will catch em.

Long Time !!!

It has been quite a busy time the last 4 months. My little baby girl was born on Jan 11 and that marks a major milestone in the life. As the sleepless nights settle I would start blogging more.

whoNeedsArchitect

http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

My fav quotes from this article --- this is what I often bring up in our lunch conversations with fellow QSI'ers!

I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate
irreversibility in software designs

Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In
short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”

“Architecture is the decisions that you wish you could get right early in a project.” Why do people feel the
need to get some things right early in the project? The answer, of course, is because
they perceive those things as hard to change. So you might end up defining
architecture as “things that people perceive as hard to change.”

Agile Methodology - Similiar to Creating Shareholder value

I have been involved in several projects now that had used Agile methodology for project management or a derivative of this method. In these projects I have assumed several roles - Developer, Team Lead, Designer, Architect and BA in a few cases.

Something I have realized is Agile method is similar to the notion in public companies - "creating shareholder value". Agile software development has iterations - 2 to 4 weeks long and then we provide improved version of software / product to the client. The client also prioritizes the new features to be developed and / or defects to be fixed. This is similar to what public companies do - a quarter can be considered as an iteration at the end of which the money matters are shared with the shareholders and  a new iteration begins. The profits the company makes is the product the shareholders are concerned with. The shareholders directly or indirectly have a say in how the company would improve profits or make new money (similar to client deciding on new features).

This idea of shareholders value creation is dangerous as well. The company tends to focus on short term gains and loose sight on long term plans. A similar thing may happen in Agile projects where lack of proper documentation, design and architecture due to short term goals (short iterations) may plague a system in long run. Of course there are exceptions - there are well run Agile projects and there are well run public companies that make profits.

Just a thought !

ERROR in Eclipse - Access restriction: Class is not accessible due to restriction on required library

I get this error in Eclipse when I use the @PostConstruct and / or @PreDestroy annotations. To get rid of this error in Eclipse change the "Forbidden reference (access rules)" level to Warning or Ignore.