Skip to content

BusinessWeek - August 10, 2005: Six Lessons from the "mainstream" software industry

A recent article on BusinessWeek Online, talks about development trends in the software industry that could also be used in the video game industry. One of the things mentioned in the opening of the article is the “mature development processes” that companies uses including CMMI (Capability Maturity Model Integration).

The six lessons learned are:

  1. Switch from Wishful Thinking to Project Planning
  2. Use an Iterative Development Process
  3. Purge Problem Programmers
  4. Code Belongs to the Project
  5. There are no Silver Bullets
  6. Catch Bugs Early

Good advice for all developers and development teams.

Borland Services offers both education and consulting services for teams and developers who are looking for capability and process improvements.

{ 4 } Comments

  1. . | August 22, 2005 at 5:17 am | Permalink

    Everyone can say - purge problem programmers.

    And that is correct.

    But we also need to say - do the say for bad managers.

  2. Jon Doe | August 22, 2005 at 5:17 am | Permalink

    Everyone can say - purge problem programmers.

    And that is correct.

    But we also need to say - do the say for bad managers.

  3. Randy Magruder | August 22, 2005 at 5:31 am | Permalink

    Interesting article, but it has its flaws.

    First, I agree with the previous comment about purging bad managers. Where do those ‘aggressive schedules’ often come from? Managers who are trying to look good to their bosses, promising more than their team can deliver. There are also overly political managers, who favor developers not who are the most productive, but who kiss their butts or can fast talk their way out of any situation without actually being able to be productive. You can’t purge the programmer without first purging the manager, in that case.

    Second, re process vs. tools. It is true that good processes need to be adopted, but if the developers have to fight with their tools to get the job done, chances are the process won’t take. Doing requirements with a simple MS Word based process vs. a proper collaborative tool like CaliberRM, or try to do parallel code development with Visual SourceSafe, and you begin to understand the pain in trying to implement processes without tools. They are go hand in glove with one another. Trying to ram one down without to other is just going to cause a major backfire.

    Finally, a key aspect of video game development is rather ignored here, which is the relatively high contributions of non-programmers (e.g. artists and musicians) — these assets are not as critical in business software as they are in games, where they are as critical as the engineering itself. Not discussed was how to apply these team development ideas to a product whose development depends just as much on non-programming assets as it does on actual code.

    Randy

  4. Robert Meek | August 22, 2005 at 10:08 am | Permalink

    I believe the real problem with this article was that it was a bit too puritanical in nature…that is in the way it took normal, everyday, business related problems and looked at them from such a narrow perspective! Whether working as a programmer, a code reviewer, a manager, or a waitress in a greasy spoon restaurant, the performance of one’s chosen or given task depends highly upon the ability to design, manage, and follow a set of processes that favor efficiancy and production! There’s nothing at all in the topical concern that is any different from any other situation when looked at from the point of view of each position necessary to fullfilling the job! there is always a management hierarchy to deal with, always choices to be made as far as designating both authority and tasks, and always some form of collaberative effort as well! I sometimes get a little tired of the pretentiousness these topical writers put on their chosen subject, as if no one else could possibly understand! In any even the problems that occur can almost always be traced back to miss-management of somekind. There is no excuse for an employee not capable of doing the work they were hired to do, and in the case where something new comes along, it IS the manager’s job to know what is or isn’t possible given his staff! If an employee says they can do it but cannot, it should be easy enough to figure out early enough so that it doesn’t become a major difficulty…that is of course, with proper management! And as far as office politics is concerned, that too should never be a real problem. Of course it comes up every single day, especially in mixed, or all female, gender working environments. But again proper management can interrupt these conditions before they become real problems…again, only with proper, immeadiate, and watchful management techniques! How do you insure good middle-level management? After all that IS what we’re talking about. The CEO certainly isn’t going to waste his or her time getting inbetween two envious or competitive developers vie-ing for the next available position in the hierarchy. Well that too is a management problem! Proper management starts at the top and runs downhill along with the rest of the sh_t, which is why quite often it seems impossible for an employee to potentiate positive change in the workplace even when everyone BUT the next level of management can’t or refuses to see it. Unfortunately there isn’t much that can be done when upper management hasn’t done their job by hiring the right managers or delegating authority in productive ways. And the only way I’ve ever found to deal with that problem is to either quit my job or like now. run my own company! But you can solve everything!

Post a Comment

Your email is never published nor shared. Required fields are marked *
Close