Can Software Get It Right For Business Owners And Professionals

Can Software Get It Right For Business Owners And Professionals
Word Count:
500
Summary:
Software has achieved the status of deity over its short fifty or so years of life. Software is all embracing in that it invades everyone’s life in some way or another

Keywords:
software development, business, software

Article Body:
Software has achieved the status of deity over its short fifty or so years of life; to such an extent that we pray to the altar of the software industry and pay homage to the organisations that invoke incantations to conjure up new commodities. In much the same way that the Egyptians constructed temples and revered them in the name of their gods, so we wait for the next sign that is passed down from on high.
Software is all embracing in that invades everyone’s life in some way or another, and as a consequence it is too huge a subject for any single organisation to completely encompass. There are notables who dominate a certain niche, but the industry is symbiotic; needing software users, Original Equipment Manufacturers and Software organisations feeding off each other to keep the snowball rolling and growing.
From the outside it would appear that these esteemed organisations have a great deal to think about. It would seem that they employ the most erudite of people, who ponder endlessly on the software that the organisation specialises on. In my fantasy moments I visualise a library-like environment with software developers sitting with a chewed pencil between their teeth and a furrowed brow that is deep in contemplation. I visualise the silence broken by footsteps and a whispered voice, deliberately muted to avoid any disturbance.
And then I awake, and realise that reality is somewhat different. Most software projects start in mushroom mode, with no one knowing what has really been sold, or alternatively what shifting market is being addressed. It is rare to include the customer in early deliberations (if at all) because inevitably the salesman has sold the organisation as being ‘market leader’ or ‘best of breed’. It would be difficult to turn around and say to the customer ‘excuse me but how do you do this particular activity’, or ‘I don’t know how this works’.
Thus the Thames barrier is raised between the customer (including the end user) and the software supplier, and a game is played out with the developers screaming for detail, and the legal beagles parrying each other. Perhaps without this facade no one would ever win a contract, but I would personally prefer to work with someone who is honest about their limitations, and who will work with you to arrive at the best possible solution to the problem.
All products evolve, no one ever gets it right first time, but we pretend we do. Whilst I agree that it takes a fair amount of trust between software developer and customer it is surely better to work together to get through the cycle of evolution than to build a glass wall which we fight over.
The customer does need to have some veto over what is happening, since (heaven forbid) there are those who will milk such situations for what they are worth, but if the product is going in the right direction, you will surely get a better outcome.

Better Software Foundations

Better Software Foundations
Word Count:
482
Summary:
It is all too often the case that Software development organizations and their customers make the same mistakes over again.

Keywords:
Better Software Foundations, software development

Article Body:
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.