Growing software keeping things simple

Back in year 2000 I was running my own software development company and had a small kind of ERP system targeted at small companies.

Reading about all the advantages of interfaces such as the ability to switch implementations one for another at any time, I thought: "Wow! That’s amazing! I gotta do that!". So I went extracting the interfaces out of each class and making the classes refer to the interface. Soon I realized that in order to be really independent, I had also to change the methods and properties to point to the interfaces so I could change the object being passed to them.

Several weeks later I had it all done and working, but those were several weeks not adding new features. Only refactoring code at a time where we had no refactoring tools like today.

One could argue that I should have done interfaces from start and then I wouldn’t have had all that work. OK, I agree. The problem is that all that was new for me. Still, all the work would be compensated by the possibility of switching implementations whenever I needed!!!

The problem is that time never came! OK… To be fair, there were a couple of situations where I benefited from using interfaces. And that only became possible because I got a new insight, a new way of seeing the world – through interfaces. But for the most part, it was an overkill. When modifying a class, instead of having one place to change, now I had two!

It has been attributed to Albert Einstein that “Everything should be made as simple as possible, but no simpler

After so many years of developing software I came to appreciate simple designs.

I think about the ways the code might evolve in the future and instead of putting in things that pave the way to this predicted future, I tend to leave out the things that would otherwise make it more difficult to get there.

The reason for this is that the predicted future may never come to realization. So by putting in stuff now, I would eventually be throwing resources away. Resources that may be needed for something else.

It gets even worse when – driven by real needs – you find yourself having to accommodate changes that go in another direction that eventually are incompatible with what was initially predicted.

All of this has already been explained by people much better with words than I am. Take a look at YAGNI, KISS and DRY.

The bottom line is: Grow you software simple. Only add complexity when really needed. Even then, try to keep it as simple as possible, but no simpler.🙂

This entry was posted in Software development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s