Better Software Foundations

Better Software Foundations
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.

You Might Also Like:

Powered by Blogger.