A blog about computers, open source, software and other perceptions gained over the years as a sysadmin.

Wednesday, February 10, 2010

Software, whats wrong with the development model?

One thing that always strike me is the way most software is developed. Its developed in an evolving manner.

You begin with a rudimentary alpha that roughly resembles the intended product. Seldom are things planned ahead in anything but a list of features the end product should have. As the cycle goes on more and more featureas are added, changed and rearranged until someone says stop. Then its down to hunt bugs down, bugs that shouldnt be there in the first place. Some are fixed, some not.

Imagine someone building anything else with the same development model. Imagine a car built without designers, engineers and experts. Made by salespeople, managers and mechanics. No planning, just slapping bits and pieces together and as work goes on fix the worst mistakes. Wrong drivetrain? We cant change that this late in the process buddy! Work around it!

Linux the kernel can make this model sort of work but its a pretty impressive feat and countless man hours are lost. People submit their work all the time and get it rejected. One wonders what it would look like if some planning would go into it all.

Im fairly certain that with proper planning most software would be a whole other beast. Instead of slapping functions onto functions you would know from the start where you are heading. Biggest reason is that when you sit down and really plan in detail you discover snags that otherwise demands you to use the software IRL before you stumble upon them.

Planning brings predictabilty, both for the developer and the user. You should KNOW in advance what a function does, why and how. Not document how it behaves after the fact.

2 comments:

  1. You have to have been a software developer to understand this.

    Although yes, planning is always a good thing, however due to the abstract nature of software, it is rather difficult to plan everything out ahead of time 100%, and have everything go exactly that way. The devil is in the details. Which is why the waterfall development approach to developing software is less popular to Agile. Release Early, Release Often.

    It is a bit like carving, painting, or a blacksmith hammering away shaping the raw materials with each hit of the hammer into a finished product.

    I don't know any artist that knows exactly how their finished product is going to end up.

    They have an idea about what they want, and through the process of development they adjust here, adjust there, and eventually shape it into a finished product.

    Same goes for software. To make things harder, you are always trying to hit a moving target. Since often during the software development process, the client you are building the product for tends to change their mind about what they think the finished product should be.

    On a related note if you want to understand what goes one in a typical software developer's mind, you should read this fantastic essay:

    http://alexthunder.livejournal.com/309815.html

    I particularly like this quote:
    "We have to build all the structures in our mind, piece by piece, and then translate them into code. Developers don’t just sit down, write out code using standardized formulas, and call it a day. No, we have to build an imaginary house of cards in our minds and then painstakingly transform every angle, force, and material into logic code, all without waking from the dream. It is a creative process, and one not easily replicated."

    ReplyDelete
  2. @Roberto Sebestyen

    You assume software development has to be abstract and all artsy. I fully agree that with todays languages, compilers and other tools its inevitable and hard to plan beforehand.

    If you cant know for sure what you just wrote does, something is inherently wrong with your model. I dont say its the developers fault, im more inclined to think its the tools and models thats wrong.

    Just like the industrialism brought tolerances and predictability to iron work i think we are in que for some development that will bring better tools and less bugs in development of software. The question isn't if but rather when and who will bring this.

    ReplyDelete