Wednesday, September 28, 2011

The Yagni Principle

There are a lot of reasons why we do things in software development, not the least of which is that somebody somewhere will find what we're doing somewhat useful which in turn will differentiate us from our competition and earn us money.  Too often, I find developers working on features that 'may be useful in the future,' while the truth is, the fancy code will likely rot before it becomes useful.  Before you write something, think of the possibility that You Ain't Gonna Need It (YAGNI).

Developers can easily come up with shiny new features, but development takes time and resources, introduces risk and complexity and doesn't necessarily add value. Not always does a re-work of architecture to accommodate some future requirement constitute a good idea.  Ideally, a proper architecture would allow us to defer implementation decisions until they are needed without impacting the existing product.

A simple principle of development is to write the simplest thing that could work. I've seen lots of applications and frameworks that do everything imaginable, but usually at the cost of simplicity.

Does this mean that I think we shouldn't plan for future requirements?  Absolutely not. In fact, I would say that all developers should architect in a way that allows for future development, just leave the details for later...when someone asks for them...and is willing to pay for them.

Friday, September 9, 2011

A note on craftsmanship

Considering that the lion's share of software development costs is spent in maintenance, doesn't it make sense that the up-front investment should be spent in making sure that maintenance is as low cost as possible?

Often times we are driven by project timelines and drop-dead dates only to be saddled with a big lump of unmaintainable code.  I've been doing some reading on software craftsmanship and admittedly, some things make you wonder if the tedium of 'extract til you drop' and 'test first' are worth the effort...after all, it seems that some things could potentially double the initial development time.

If 75% of software lifecycle is in maintenance, and 25% is in initial development.  Suppose I double my initial development; if my maintenance is costs are cut in half, then I've saved about 12.5% of my overall cost of development.

25 * 2 + 75 *.5 = 87.5%

If I can reduce my initial development by half, but it doubles my maintenance costs, then it will eventually cost the organization an additional 62.5% more than it had to and as much as 75% more than it would have if I had just spend some more up front time making code maintainable.

25 * .5 + 75 * 2 = 162.5% + 100 - 87.5 = 175%

Easy math for the brass.