Software Development in 2005 - Back to the Future

2005 ? Back to the Future.

What does the future hold? A big question and initially the answer is anything and everything. The predictions are sometimes close but most of the time they are far from the reality. Technology has moves on apace and the core players in the various sectors of the computing industry invest in research and development which increases the rate of technology introduction with performance improvements or benefits outweighing the previous technology that customers/users/consumers must take advantage of, or so that is what they tell us. What is the truth? And what is the future?

For the developer community I believe that things have not changed all that much other than there a more defined lines to be drawn between types of developers i.e. games vs corporate applications, mobile vs military. These differences are reflected in the methodologies and tools used by each group. However, the principles remain the same, identify a requirement and then satisfy that with some code. The implementation various by user requirements. I spent four years in the late 1980s working on Software Engineering and Systems Engineering products at Digital Equipment Corporation (DEC). The focus of the team I was part of was to build an integrated environment that utilised Independent Software vendors products in a framework that enabled the output of one product to flow into the others as needed. This was done with customer input through a direct mechanism of regular meetings and information flow to create a generic specification that could be used in industries such as Aerospace, Defense and Telco. This was the time for quality processes, analysis and design methods and a burgeoning open standards movement. This developed into the Open Source movement and the associated issues that brings, but that is another story!

The premise of building an integrated environment that encapsulated a range or products from leading vendors in the key parts of the software development cycle was, and maybe still is, the holy grail for software and systems development. Incorporating the process model and flow into the environment enabled two of the critical elements of development, a controlled process management capability and the right tools for the right job. What you find today is an integrated development environment but you cannot use other tools that you currently use to do functions such a requirements tracking, documentation, code management, etc. The important thing to note is that the environment that DEC built, with a range of partners, was used to create the software on the then leading aerospace project, the F22 fighter. It was used in anger and it worked. It may have been ahead of its time but it did the job.

The non-technology element that an integrated environment does not adequately address is the people. This is the vital part of this process of any software development project. Instilling discipline across a team is not easy and does not get the focus it should. Many have tried to raise the awareness of the role people play in software development, such as Tom de Marco, and the issue is that developing software is still seen as an artisans job and not a true professional role. The British Computing Society Chartered Engineer status provides for individuals to be professionally qualified but my perception is that the number of people who have taken the time and trouble to qualify is limited. If more projects asked for chartered status of a significant proportion of the project team there would an improvement in the delivery of projects on time and in budget.

So what is my point. Well, it seems to me that we have gone backwards with regards to software development technology. The ability to integrate and get individual components from separate vendors to work together is one thing, to get them also to work together with a work flow model is another. There may be suites from individual vendors that offer this but if you want to retain your own environment you may not be able to. This then involves a major change in your development process and teams. No one likes change! So we all stick to our known quantities to keep in the comfort zone.

More importantly the role of the human in this complex and technology based process is not fully understood and nor is it managed in a way that achieves the best results. People need encouragement, they need motivation, guidance and above all the knowledge that what they are doing is of value. My view is that all projects now come down to money and time, and whilst these are important from a business perspective, the measurements miss the impact that these have on the people involved in the project. There are changes that must come from the business in terms of measuring quality such as the reliability, use-ability and flexibility of the software as well as the quantitative measurements of keeping to time-scales and budgets. The developer needs to do their bit too in this equation. They must become more professional, become a Chartered Engineer, and be prepared to change and understand the business dynamics, because after all they are paid by delivering code that works. And most people understand that premise.

Paul Bellchambers

Paul has over 25 years in the computer industry working in the area of software development. He has worked for Digital Equipment Corp, Sun Microsystems, Olivetti Systems and a number of companies developing software applications. He is currently running a new developers website - http://www.thedeveloperscatalogue.com - and he is also writing articles for the site and for other publications including International Developer Magazine.