IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Differences in Software Systems and Software Development
I think he's onto something, if I may.

The difference is that there are two stages to software development in major companies.

First - there's the software system. When they add new programs they have to determine and define what functionality they're going to add. This is where we get marketing and others and figure out what they going to do. They then get managers in there who look at what people want to accomplish and try to scale the work to what their team can perform in the time required. Furthermore, they then have to understand who's going to test the code, who's going to build it; and how the code is going to get into production.

IE: your basic CMM model

They try to address some definite issues

  • Undefined/misunderstood requirements
  • Scope creep
  • Maintaining the system (all projects)
  • Standardizing Processes


Then there's the software development side of things. Here what matters is not what the requirements say - rather we're making the software do SOMETHING. I can't speak for others, but I've found that during development, I try and figure out those items that I don't know how to do (and are required) first. A general skeleton of the code is developed and unit tests are developmented. More meat is added until the code looks like what the user wants.

Even if we look at (some of) XP's issues:

  • Pair programming
  • Automated Unit Testing
  • Code Reviews

And it's obvious (to me) that we're discussing how to develop the code. Not the steps in how to justify the expense, scope it, manage it, etc. Personally, I think that XP is often given as an approach for Software Systems, where quite frankly, I think it will fall on it's face.

However, at the Software Development level I think XP may prove to be effective. Most arguments regarding design and documentation at the code level are flawed. I've seen more comments in code that are out of date - or didn't belong, than I care to imagine. Documentation (other than external documents to be used by other groups) regarding code are worse than these comments, imo.

Furthermore, while CMM has proven, for code generation, to develop bug-free code, it does so at a price-per-line and time-to-market that are unacceptable to nearly all development houses.
New Risk Management
I think you've struck upon one of the KEY factors of project success right there that no one mentions.

Trying "experimental" things first, proving them, then moving on to the more routine parts of the system.

One of the other really good code books I read, I think it may have been Code Complete, said that developers really must try the "experimental" parts of a system first. The high risk stuff.

The reason, from a business perspective is obvious. If some key "new" component of a system, or business process, or approach DOESN'T work, then there really is no need to continue funding the project.

Yet, of the large project failures I've been involved with, exactly the OPPOSITE has happened. The project manager and developers do the things they are most comfortable with, spend the majority of the money in the project, then discover that the key "NEW" thing doesn't work. Ooops, sorry we took your money. We were billable by the hour, so we can't refund it to you.

This dichotomy occurs because most consulting outfits are operated off of "billable hours", and so they want to bill as much as possible before the "unknown" parts of the project are tested. It's a key reason, I think, that many people are avoiding the likes of EDS/IBM GS/etc. for consulting. ( It may even be one source of reasoning for outsourcing overseas. The thinking goes, "If we can't trust the largest, most established companies in America, then who can we trust? We might as well try someone else, less expensive." )

Bob Lewis, the former columnist for InfoWorld in the management arena keeps preaching 3-6 month engagements. His philosophy is that you give them the risky stuff first, see how they handle it, then decide whether they're honest enough to make a permanent part of your team.

I really like his thinking.

Glen Austin
Expand Edited by gdaustin Sept. 2, 2003, 11:28:29 AM EDT
     Extreme Programming Considered Harmful - (admin) - (12)
         Talk XP or Do XP? - (gdaustin) - (3)
             The project that failed in the paper... - (admin) - (2)
                 Re: The project that failed in the paper... - (deSitter)
                 Re: The project that failed in the paper... - (JimWeirich)
         Differences in Software Systems and Software Development - (Simon_Jester) - (1)
             Risk Management - (gdaustin)
         His unanswered questions list - (Arkadiy)
         Re: Extreme Programming Considered Harmful - (JimWeirich) - (2)
             Precisely -NT - (tuberculosis)
             Jeffries' review of "Extreme Programming Refactored" - (JimWeirich)
         Everything Considered Harmful - (ChrisR)
         The good thing about XP is that... - (tablizer)

You signed the Memo of Understanding...!
80 ms