Better Software Foundations

It is all too often the case that Software development organizations and their customers make the same mistakes over again.
I visited the ruins of a Roman settlement, the other day that was set in a lovely valley in the middle of an island.

The setting was idyllic, sheltered from the winds and not too far from the main market town, it seemed an ideal spot to farm and bring up a family.

Its history was thoughtfully provided on signs around the ruins of a substantial dwelling, which had been expanded in Roman times to include a hot and cold bathroom and mosaic floors. All of this was very attractive and a considerable investment for the landowner. But the settlement was abandoned, and it occurred to me that there had to be a good reason since it was clear that someone had put a lot of effort and finance into their dream.

I wondered if Vikings, who were known to be active in this area after the Romans left, had attacked it but there were no signs of charred brick work or the aftermath of battle.

Looking around another sign revealed the problem. There had been more than one attempt to settle the area, but the land formed a natural point of drainage for the hills around, and successive buildings had each eventually succumbed to subsidence.

I was left in no doubt that the buildings were of a good quality and that the builders were competent at construction, but clearly it had taken a few generations to work out that this was not a suitable site for construction. If we really wanted to settle this place now we would drive piles deep into the ground to overcome the subsidence.

The point that this drove into my mind was that of developing software. It is all too often the case that Software development organizations and their customers make the same mistakes over again. If the foundations are shaky then there is no point in building, but with a little forethought someone will could solve the problem and provide a safe way of delivering a good foundation.

The biggest mistake that organizations make is to rush to cut code before they understand the problem they are solving. That doesn't mean you have to be complacent and that sitting around in a few meetings will solve all your problems.

What should be done is: -

Ring fence what you know.
Ring fence what you don't know.
Make sure you are developing the right product.
Build the software that you know will not change.
Check that what you are building is what is wanted.

Often the customer just doesn't know exactly what they want, so you need to involve them in the development process. The earlier they get to know the product then the more likely they are to buy into the solution.
Having said all of that..

Code should be built where it enhances the understanding of the problem both to the customer and the developer.