An Opportunity for Open Source : No
Some may consider that Open Source is the answer to this, but that's because Open Source gets it's reputation from a relatively small number of successful projects all of which have a large number of contributors and active members. For the most part these are done as a hobby, for the sheer love of it. Unfortunately software produced by companies is done for rather different reasons and love isn't one of them. Opening your source code will not automatically guarantee your software will get developed at all never mind on time. It does however guarantee potential attackers can see if there are holes in your software.
Programmers in business are under tight schedules to deliver so there is no time for love, time consuming optimal solutions are forgone in favour of quicker implemented approaches. Open Source teams may have found a solution to these problems but without the love this technique won't help business.
The Real Problem
The biggest problem is that software is complex and as it grows it becomes exponentially more complex, no single developer is going to see the whole picture. Even if they could the skills required to understand the big picture are different from those required at the code level. Coding requires a good memory of techniques and the ability to use the right techniques to solve the right problems, creativity isn't really a requirement.
The big picture, the Architecture, is a different area altogether, it requires the ability to solve problems without an answer, it requires creativity, the ability to design. Software developers are trying to solve this problem by applying the techniques of software development. Software development can be taught: you have this problem, you use this solution. Design is a skill, as such is also great deal more difficult to teach it.
Software Architecture will become popular, then a legal requirement
The original idea behind Software Architecture is to use a top down approach - to produce a design first then start developing. Unfortunately this method (referred to as the waterfall method) doesn't work very well for systems which change and large systems tend to change.
One method which does work is a formalised method of the bottom up approach called Extreme Programming [5]. This method advocates the use of small iterative development stages and constant refactoring (the cleaning up of software). In Extreme programming there is no large design phase at the start, instead the refactoring technique allows a design to evolve into existence. You don't know at the beginning what the end result will be. While this may sound counter intuitive for non-programmers this method works very well. The changes which mess up so many systems are caught and handled by the refactoring.
Modern Software Architecture methods have a large initial design phase but the design is continued alongside an iterative development process. Actual code tends to move away from the initial design so the design is tracked as it changes, when a new requirement is added or something needs to be changed the Architect can look at the overall design and modify the design before coding of that change begins. This is process is similar to the refactoring used in Extreme Programming but is done at the Architectural level first and later at the code level
The benefit of this approach is that someone always knows what they are actually building, what fits in where and effects what, as such it is much easier to make changes and keep the software maintained. Some Architects already use a iterative Architectural technique and Extreme Programming as the development model with success.
Managers and developers may currently see Architecture as an extraneous phase but when businesses realise the productivity gains and cost savings it can deliver it will come into focus. If a change at the design phase takes 1 day, it will take 10 days if made at the development stage and 100 days if made in the maintenance phase. Given software spends most of it's life in the maintenance phase Software Architecture makes a lot of commercial sense.
When liability becomes a major issue the reliability and accountability Architecture can deliver will be seen as the key to producing better software. Software Architecture will becomes a "real" job complete with real official certifications and liability. I don't mean company based certifications as is common in the technology industry today, these will be industry wide with legal standing. It'll be a difficult, risky job but we can learn from the past, the exact same thing happened in the building industry many years ago.
Some people have seen this process coming and formed their own organisation [6]. There are many books to be read for the aspiring Software Architect. Many programmers already have the requisite skills but probably don't know it, Architecture is a different area and you'll find out if it's the area for you by reading some of these books which cover the different aspects [7] [8].
Unlike the building industry software development can be closely monitored, I expect we will see real time tools for visualising and monitoring architecture. I also expect that development models will evolve. Some models are huge and require a great deal of complex and expensive tools, others are too simple and end up with chaos. Consequently I expect we will eventually find a happy medium where an extensive design phase is followed by a process similar to Extreme Programming. I also expect testing will also play a much greater role in development.
Wither the Penguin?
Some have suggested that Liability will kill off open source, is this true? Will the penguins shuffle off back to the South pole?
I do not expect this will be a problem for Open Source development, it could in fact have quite the opposite effect and make it more popular than ever. If you are liable for your product you will be very keen on using tried and trusted technology. I expect the model used by Java and Perl programmers will become more popular, they use a great deal of Open Source modules in their systems.
For Operating Systems IBM, HP and friends can all control and make sure their own in House Unix systems are ready for liability, Unix isn't dead yet by any means and this may keep it alive for a long time yet. I don't expect the BSDs will have too many problems, they are generally created by smaller teams and FreeBSD, OpenBSD NetBSD all focus on stability anyway. OpenBSD focuses on security but stability is a pre-requisite for this. NetBSD is more research orientated but it's ultra-portability means it too has to be a highly stable system.
Liability may prove difficult however for other systems:
Small modules even of unknown origin can be checked but it's a different story for large monolithic systems such as linux, would you trust your life to Linux? Given it's distributed development model who's going to accept liability for it? This wont kill Linux but will lock it out of some applications until these issues are solved.
Microsoft will have to accept liability for Windows, when they decide to do another security binge they will have to do more than a marketing excercise. Microsoft have built their empire by building software which works most of the time, I expect they will have a hard time adapting to developing software which works all of the time.
- "Future of Computing, Page 1/3"
- "Future of Computing, Page 2/3"
- "Future of Computing, Page 3/3"
