A380 is not a banking software system
Ecris le 21 janvier 2005
Dans la catégorie Uncategorized |
A current discussion on the XP mailing list is about the A380 project success story, and what lessons could be learned from it.This is a quite common mistake to try to compare software development activity for business systems and the industry. The two domains are radically different for many reasons. Let me point two of them.The plane usage conditions are totally knownAll the physical laws that will constitute the plane usage environment are known. It is hence quite easy to design the solution (the plane), and to automate its construction.This is not the case for the software. Most of the time, nobody knows how will be used the system, in what context, and for which purpose. And if at some stage we can know it, there is good chance that those context and purpose will change, and quite rapidly.The manufacturer knows what he’s doingIn the plane industry, everybody knows what a plane is. Even the guy who puts the bolts knows why he is doing it, how this bolt will interact with other piece of the plane, and what will happen if his work is not well done.Again, in software development context, the programmer does not know the business he is coding. He is not an accountant, or an air travel broker. He does not what is complex, or not, and what is important. Even worst, in some case, even the users don?t know it.I think we should stop to try applying industry solutions designed for industry context, to software construction. I am sure, however, that XP is a good solution to real problems of the software development activity.A380 context is driven by physical laws, banking software systems are driven by human activity. That’s make all the difference.
Social Bookmarking
Commentaires
2 commentaires to “A380 is not a banking software system”
Laisser un commentaire
Moreover your analysis, another widespread mistake is about product and solution.
Industries are product centered : sales, marketing, production, services (usally to boost sales process) are focused on product delivery to market (feature implementation just defines a market position) . Considering products, client is a buyer (and an integrator) and simulated during the software devlopment process.
Business systems are solutions, specially financed, designed, developped for real requirements/scenarios. So, client is designer and developper of his own solution (not integrator).
Softwares could be developped as product :
Microsoft, SAP, … makes products : CMM 30 000 is required with strong testing process (as they should be for an aircraft).
Or, as solution :
IT services (internal or external) make solutions : client focused is required! So agility is needed with a strong testing approach (functional and technical).
About cost, commonly people says products are cheaper than custom solutions. What about co-development, specially for small companies? Features could be mutualized between different final clients (domain patterns identification, in fact). Moreover, user story segmentation could facilitate co-development. What do you think about it? ben.
The software product myth
While the A380 air plane was launched, software industry people remarks our current unability to produce great software, because a lack of strong industrial process (CMM, man-month interchangeability, …).
Bernard Notarianni precisely notices that A3…