For Finextra's free daily newsletter, breaking news and flashes and weekly job board.
It always suprises me how many Senior managers just don't get it. Agile definitely helps resolves some of these issues. I can't understand for the life of me how anyone can deliver using Waterfall now.
Paul, your list might or might not be accurate but you somehow forgot 2 top reasons that by far define the IT/software industry:
1) Client CIO's first and foremost loyalty is usually to his/her own morgage and transportability of his skills. When the project fails the original CIO is already likely being far far away.
2) Vendor upsells what s/he has, never downsells (is it a word?) what the client needs - explicitely or implicitely.
Exceptions do happen - according to the numerous stats as much as 4% of all large IT projects are on time and within the budget. If the client is that lucky, he should visit Makao.
Excuses, excuses, excuses...
This list is self-admittedly applicable only for custom development projects. Many software projects involve customization and implementation of standard products (e.g. SAP, FLEXCUBE, etc.). In case you're planning to write separately about what makes such
projects hard, here's one item to kickstart your list:
Drastic difference in what is expected from the software before implementation starts versus what is accepted after implementation ends. To cite an extreme example, many companies embarking on an ERP project expect the software to change the fabric of their
company before starting the implementation but are willing to settle for accurate invoicing after ending the implementation!
Paul, this is one excellent compilation of why building software is so different than building manufacturing projects. It is much harder to evaluate good code and determine whether software is 'successful' at it's goal, relative to whether a bridge or tunnel
is successful at allowing the safe movement of traffic. Of course, the purpose of the software project, i.e. gaming software, versus operational software for a life-saving medical device, will also determine 'how good' the software needs to be. With the 'algorithmic
trading' software nightmares of recent days that threaten to take down markets and established companies, the level of quality and reliability needs to be set early on relative to the purpose. Software cowboys need to grow up and take their projects as seriously
as structural engineers do when building skyscrapers. Better Quality Assurance, Testing, and extensive Alpha and Beta cycles are needed gain that first hand feedback that end users cannot possibly provide until that point in the dev cycle.
Consumers need to value important software more as well. Right now, with respect given to your number 5, anyone can hang out a shingle saying they are a 'software' development house. But not anyone can provide an ERP system, or banking system of record,
or algorithmic trading platform. There is great value in software that works.
Hopefully, as the industry matures, a more pervasive understanding of the challenges you list will drive better software builds.
Excellent post with many good points. But at your premise you compare software to construction. Another notable difference in this space is that the standards construction is based upon (units of measure, materials) are significantly more standard than
the base units (operating systems, hardware platforms) for computing. This is not just a function of youth, but certainly adds complexity to software development.
I would be interested to hear your perspective on how much this factors into the issues above and what you think should be done to address this.
To those who commented on my article - Many thanks for your feedback.
In a short article such as this I couldn't address all aspects of software development so all the comments just add further weight to this topic.
Yes it is primarily written from a custom development point of view and reflect 30 years of experience in this area. However, I've also been involved in many CRM and other packaged software implementations and despite the fact that they are supposed to be
easier to implement because it's off-the-shelf software, I can safely say that that is not usually the case.
Regardless of the type of software, custom vs packaged, I see as much confusion in the minds of users about what they really want and expect as Ketharaman points out in his comment.
Brian's comments reflect many of my own beliefs. The term "Software Engineering" is used a lot. Mistakenly I believe. I don't think software is yet as disciplined a profession as engineering. As an industry there is still a long way to go before we can call
ourselves real engineers.
Gregg is absolutely right in pointing out that the base units in software development are much less defined and stable as in construction. I immedately think of an analogy that building software on any platform is like building a skyscraper on quicksand.
Kynetix Technology Group
08 Aug 2012
This post is from a series of posts in the group:
This community aims to provide links, resources, book suggestions, tips and insights to facilitate learning and development of IT professionals in financial services, and to develop a forum for IT professionals to exchange views on various related items.