Real World Software Architecture: Thinking Software Development Process Implementation is Free means the Blind are Leading the Blind, but there are Ruby Slippers that may Help.
This posting has been triggered by a very interesting posting I read on Tad Andersons blog, Real world software engineering, about development processes and more to the point the implementation of process within
software development organisations.
This area is of particular interest to me, like tad I have considerable experience and night mares surrounding methodologies and processes. But rather then extending upon Tad posting or echoing all his comments, which I agree with 100%, I intend to cast them in a different light, from the perspective of a business model for software development.
So before we jump in I will outline some of the fundamental principals upon which all my arguments rest:
1. The development of software is not a simple undertaking which succeeds without a formal plan and map as to how the ‘application’ is going to be built. Other words one can not just sketch out a few ideas and expect a developer to sit there and turn out a fit for purpose functional application.
2. Methodologies with proven track records do exist, which when applied correctly will allow a group of people to collaborate and deliver software applications.
Therefore an organisation that’s core business is to develop software application MUST has in place a highly developed process, assets and tools, as nothing is for free in this world the organisation must of invested hard dollars in their process.
To directly answer Tad’s question “What makes people think a Software Development Process can be implemented in an organization at no upfront cost (including time & money)? They think this simply because either they are poorly informed.
To understand this further lets take a healthily business model of a software development firm. In the past when I have sat down with this type of companies and ask them how do they think they make their money, the answer I get 75% of the time is “we bill our clients for our work”, my followup to this answer is “what margin do you work towards” and from here I get an answer that range from 30% to 200%.
My next comment is what normally upsets everyone in the room, “So your company makes money by hiring people and billing them out for cost plus X%, so in essence your company is a body shop.”
“No you don’t understand” is normally the objection; then they try to explain that they are a technology company and how they have processes, intellectual property, etc.
The reality is that most software firms out there are body shops, in that they only profit from margins on human resources, now that is not to say body shops are bad or useless, this is far from the truth, but they are also far removed from what I call a software development house.
From my perspective a software development house is an organisation what can deliver to their client’s, custom software application and/or solutions, for a cost what is lower and a quality which is higher, then if the client decided to put together their own development team to build the application. So how does a company achieve this, well it is via processes, assets and tools. Before drilling down too much lets take a look at a manufacturing company in particular one that specialises in die casting.
That factory, besides its staff and raw materials, would have a large amount of infrastructure they have invested in, infrastructure that would allow them to manufacture components quicker, better and safer.
The same applies for a software development house, they would not have only invested in their people but they also would have invested in a process/methodology, which is akin to their production line, they would have also created specialized tools and that would have framework components they can reuse.This allows them to produce code quicker, clean and much more reliably then the local software body shop. Hece gainig a competitive advantage.
So from my perspective it is probably the body shops that want to implement processes and due to their culture and the nature of their business expect or don’t want to pay for it.
The other area where software is built which I have not covered is within organisation’s which core business is not software development. For example an Insurance company, their core business is underwriting and risk, now that business would have plenty of smart folks and financial resources to develop software in house, but would they want to? After all they don’t make money by producing software.
Given there are situations where they could develop in house and most of these situations would probably relate to non mission critical applications that delivered productivity improvements rather then core business operations. In these situations they would still put in place processes to protect and guide their investment in the code base that will develop of time, methodologies like Agile and XP are just so fitting for most of these situations.
In conclusion I believe it is clear from the above, Tad’s posting and other published resources that you must have process /methodologies in place to turn out quality reliable software and that the processes themselves are a competitive advantage in the right business setting.
Coding outside a methodology and a architectural pattern or paradigm is something for strictly for the weekend coder, and if the business can not operate on that basis then get professional.
