Why Software Methodologies Don’t Save Software Projects

Rigid Systems Can’t Save Software ProjectsAccording to Wikipedia, in Software Engineering, a Methodology is defined as:

A codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

Unfortunately, that definition is believed by many, and it’s dead wrong. If you believe it, your projects may be doomed to failure.

Methodologies are systems for the creation of things. A system designed to manufacture cars at Ford or hamburgers at McDonalds is a methodology (although not a software methodology). Ford manufacturing plants produce new cars through an assembly line where each phase of construction is extremely well defined. It’s defined to the point that even robots participate in various phases of construction. You can interchange people who work in the assembly line with relative ease and almost no impact on the end result. There’s quality assurance at every phase to ensure that each benchmark is within the predefined limits. All of this results in the manufacturing of nearly identical cars, in every single instance. It works great.

Likewise, McDonalds has a similar strategy for making hamburgers. The steps to create a burger are well defined. If you change the cook, the burger will still be the same with the same amount of materials, same ingredients, same cooking temperatures, same sauces and the same wrapping. McDonald’s burger-creation methodology results in the customer enjoying the same burger, every single time. Their success is proof that the system works and it works well.

Methodologies Don’t Produce Software

So why not a system for the creation of software? If Ford can do it for cars and McDonalds can do it for hamburgers, why can’t we have a system to produce software? The answer is that we can. The catch, however, is that the system can only re-create software that has already been created. The system cannot produce new software just as Ford’s methodology for creating new cars will never create a different kind of car. It’s designed to re-create the exact same gas-guzzling, poor quality, tire-exploding and boring car in the exact same way that you have come to expect from Ford. So it is at McDonald’s. The system doesn’t create a new kind of hamburger. It simply re-creates the same bad-tasting, low-quality, high-calorie hamburger that you’ve now come to expect from McDonald’s.

In the same light, a software methodology cannot produce new software. This concept is a major surprise to a lot of companies and the US Government, who after spending hundreds of millions of dollars on software projects that end up being canceled — projects that should have been fool-proof in their success. After all, they used the most concrete software methodologies known to man-kind (or to Grady Booch). How could such software projects fail?

Learning that methodologies or well-defined systems and processes can’t create things is important. People create things. Systems and methodologies can only re-create things, but only after people create them first. So what about successful software projects that have employed rigid systems and software methodologies? Easy. Such projects have succeeded in spite of the methodologies used, not because of them and it’s virtually guaranteed that a less restricted team would have accomplished the same task in less time.

New Trends in Software Development

The world is slowly coming to the realization that people are the most important part of any successful new software project. No systems or processes can substitute for your top software engineers. Take your own software projects as an example. Would you give up the top one or two team members or would you give up your software methodology? My guess is that the answer is a no-brainer. Even in a team of 100, losing the top couple of team members would be far more detrimental to the success of the project.

You have undoubtedly heard of new software methodologies such as Agile and Scrum. The popularity of these new light-weight systems is exactly because of the reasons I have explained above. They put the emphasis on people. Is it any surprise that trimming down detailed, process-heavy, software methodologies has produced much better results? Of course not. These new systems are putting the emphasis on individual team members, finally coming to the acceptance that the individuals are far more important in the creation of new software. The systems should only support the individuals, not get in their way. Unfortunately, even these new methodologies are slowly becoming heavy. Scrum is becoming better defined by the day and the more it gets defined, the more Scrum Masters who insist on having a burn-down chart from day 1 on a new project, the more such projects will suffer.

Finding the Right Balance

Like everything in life, there is a balance that each team must obtain between systems and processes and team and individual freedom. Each project is different. There is no one system that can meet the needs of all teams and no single implementation of a system that should be used instead of another. Google’s founders didn’t start with a methodology. Neither did YouTube or FaceBook. Even well established companies like Microsoft and Apple didn’t (and still don’t) have rigid systems in place and they provide significant team freedom to choose the right amount of process for their projects.

So unless you have a lot of free tax-money to waste or if you work on human-safety systems, reconsider the weight of your software methodology. In software, lighter is usually better.

  • http://www.tril0byte.com Mike

    I agree with the people is the most important view. However even though I agree Ford and McDonalds aren’t to my taste ripping them after explaining their methodologies was uncalled for in your article. Please stick to professionalism and your expertise, which is software. I find the most important thing for releasing software is response to change of requirements and being able to implement them quickly. Most software “methodologies” are too strict and slow to respond…

    Thank You,
    Mike H
    http://www.tril0byte.com
    Home of Crypt Guardian

  • Russ McClelland

    While I love using OnTime, I couldn’t disagree more with this posting. I think the biggest thing missing from this article is perspective. Methodologies can be viewed from different perspectives. While it is true that people create software, people can capture the things that worked well in that process and things that didn’t work well. Using these “best practices” is a methodology. Sitting at your keyboard and ignoring these “best practices” is also a methodology. Neither will guarantee success. One will increase your chances. So what is the perspective here? That SDLC methodologies aren’t processes to create software. Instead they are the next higher level of abstraction. They are processes that govern the activities that people use when creating software that have evolved and matured based on the experiences of those that came before us.

    The premise of this article is that because your are writing software that has never been written before, a methodology, analogous to the McDonald’s methdology, cannot help you. But how much of our software is truly unique? How many of us has coded a system with data stored in a database and presented on the screen? Did we map fields in the tables to objects? Did we map them to UI widgets? Did we update the tables with values from the screen? How much of that code was truly unique? Not much, hence the inexerable march towards more value in the components we use. In the past, we all coded transaction processing code. Now we use application servers. We all coded workflow in our apps. Now we use workflow platforms. And portal tools. And communication libraries. And…

    I’d argue that a more realistic metaphor is a recipie. Yes a person created the first version of some tasty dish. But, following their directions significantly increase your chances of creating the same tasty dish. There is still a chance you’ll miss-read “cinnamon” and use “cumin” instead like I did the first time I made hot chocolate, but your more likely going to end up with a masterpiece.

    This is the promise of methodologies: quit this insane notion that what you are building is so unique that you can’t stand to learn from other people’s successes and failures. While your software may be unique, the issues you run into aren’t.

  • http://www.squidoo.com/U-ASK4-IT GeorgeB

    Change IS the constant.
    So, the goal is to have a system/process of :
    – dynamic feedback, and
    – useful responses
    Just ASK4 it..24/7 !
    ;-)

  • http://www.siliconglen.com/news Craig Cockburn

    Once again the word “methodology” is misused. Methodology is the analysis of methods. I think you meant to say “Why development methods don’t save software projects.”

  • http://alistair.cockburn.us Alistair Cockburn

    I’m not sure why people feel up to disagreeing with the dictionary, even to go so far as to say “it’s wrong.” Dictionaries are pretty careful about their definitions, and have been for centuries.

    Both English and American dictionaries agree on the definition of methodology (words vary slightly by dictionary, of course). Here is one from the dictionary.

    “1. a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or s
    sciences.”

  • Pingback: Putting it All Together: PureChat « Ship Software OnTime!

  • Ted L.

    Hi Hamid,

    I have noticed some mixed comment by you about SCRUM (you like its people oriented approach and dislike that it may become too-defined and strict for your liking). I also have noticed on Forum that many Ontime customers are asking repeatedly about supporting Agile and SCRUM and other methodologies within Ontime.
    You even have forums:
    http://community.axosoft.com/forums/thread/11802.aspx (I have asked question in Sept.07 – no answer)
    http://community.axosoft.com/forums/thread/13479.aspx
    Quote: “but honestly Axosoft knows nothing of Scrum, and they are unwilling to tweak the product to support Scrum. I really doubt that many Scrum shops are using OnTime, but that would change quickly if Axosoft were willing to listen to their customer base.”

    Does this mean that you will be unwilling to listen to this growing number of people using SCRUM and other methods, since you disagree with them? Most people comment that they like Ontime for simplicity, transparency and many other nice features, but it lacks few extra fields and reports (burn down chart :-) ) and there is not enough flexibility with custom fields. Please comment. On the positive side for Ontime, by adding support for such methods (without compromising core of Ontime) you could have expanded your customer base by a factor of 10.
    Same question I have asked about supporting ITIL (or at least some of it) , and that is also not possible with Ontime, as Related Items doesn’t really do much and it is not possible to link Incidents to Defects and no ‘knowledge base’ exists at all.

    The truth is, that we as a company suffer more often, not because we have a too-strict methodology , but quite the opposite, because we don’t have any fixed methodology at all. Having grown from small company to 25 people company. Ontime product , as great as it is off the shelf product, you can buy it or not , when you bought and you want to change it, Axosoft may do the change (in some new releases) or may not at all. Our customer base is different and we need to supply customer’s demand (estimate, quote, commit to a timeline, test and deliver, commission, provide user training and then get paid) and respond to incidents 24/7 as it is time critical applications that we build. So as much as I like your free-spirited approach and having to build PureChat in 60 days – which may sell well and become another winner for you. We may not always be able to take time off and turn off our phones for 2 months. Some requests that I have submitted to Ontime more than 6 months ago , may never be addressed as there is no way I as customer can leverage your decision (we even tried to pay) to build something. So for me as customer – reading that all your team worked on some new idea is a bit sad, as it means that no one worked on features that we require for our businness (and I hate to buy yet another tool just to address one need). Mind you, we may conside PureChat for some support applications :)
    I agree with lighter approach, but having no methodology at all rarely helps. All the best.