Comments on: High tech: Software development’s “black hole”

By: Mark

Mark — Thu, 09 Jul 2009 02:16:43 +0000

All of my comments are related to Fortune 500 companies.

By: Mark

Mark — Wed, 08 Jul 2009 13:44:00 +0000

There are many ways to combat your issue of slipping time lines and budgets. One use an Agile methodology (it’s hard to be late in a two week sprint), and the second is proper tooling. Too many developers hate being controlled by process and tools–that’s the issue. You must have Executive Level support and implement the right tools and process as well as a Business Intelligence (BI) ability. Then you will have very high predictability for your projects.

I have seen failure turn into success many many times by doing these two things (and in some of America’s largest companies). The BI component is new and there is really only one company that can do it (although a few companies like Motorola have built their own).

Adding BI to your development data just as you would to your customer data gives you HIGHLY accurate info on your current project status as well as predictability for the future.

Development is now a science…not art.

By: Steve Wilcenski

Steve Wilcenski — Fri, 03 Jul 2009 12:44:42 +0000

If software project specifications were easily quantified, say a project is to deliver 6 Performance Nicks, and development staff then had only to deliver 6PNs, the development and deployment teams might have a shot at making deadline and budget. Requirements and specifications, however, in every project I’ve known, are allowed to change. This, naturally, makes the expected software change, to say 6.75 PNs. Or more. I’ve never seen less except in cases of cancellation. The mere process of settling-in minor modifications disrupts what’s already in-process.
Requirements and subsequently specifications need to be frozen before development and deployment start. Not realistic? That’s correct. Since reality dictates elasticity to account for real changes and inevitable design, even requirement, omission and error, appropriate changes to time and expense of development are necessary.
IT consumers cannot ask for five pounds of potatoes, and when getting to the checkout counters, after the total has been rung-up, declare the potatoes need to be au gratin, and roast beef, red wine, and Baked Alaska are expected.

By: Burckhardt Rueffer

Burckhardt Rueffer — Fri, 03 Jul 2009 00:36:48 +0000

One additional factor that is often overlooked is the localization part of the development cycle. Even if the developers have taken all the necessary steps to “internationalize” their project, getting it localized is often considered an afterthought.

Good planning involves getting a system in place where lines are drawn. These lines identify milestones where all players and parts of a project can be synchronized. Small steps help. Fewer decision makers and a clear definition of what is and what is not included in a release help too.

I have been involved in the localization process for many companies, from Big Players all the way to small companies with a niche product. Unless localization is included in the project plan it will cause delays. By the time the project is localized the coders have fixed some bugs, added some features and the localized product is out of date.

Software localization companies spend much of their time working with developers and project managers. Using the localization cycle as buffer helps identify and fix bugs, including those that would remain undetected if development were only aimed at the local market.

Don’t underestimate the value these localization professionals can add to any software development project - they likely have been through the process often enough, for different clients and projects. Getting them involved early can save time and money and will improve the product.

And - ultimately - it may happen that a project is released on time, with all the features and within budget.

By: James T.

James T. — Thu, 02 Jul 2009 12:51:34 +0000

Coming from over 25 years in the software industry starting out as a programmer and now advising on software engineering processes, I use the same analogy of writing code being the same writing prose all the time. It is an art rather than a science.

Having said that, I think there are two things that stand out in my experience to throw projects off schedule/budget. 1) squishy user requirements 2) poor time estimation/management.

Most projects don’t do a good job of nailing down user requirements (e.g. I don’t like the way the screen looks) which causes the developers to have to write and then rewrite code.

Most good coders are poor estimaters/time managers. They are the creative (it’s an art, not a science) type rather than the organized type. So, while they can write great code, they are poor judges of how long it will take to write that code causing the schedule to be unrealistic.

Now, as most familiar with the Project Management Institute (PMI) will tell you, there are many (20 according to a PMI study a few years ago) causes of project failure, my sense is that the two I mention are particularly reflective of software project failures.

By: Tim Colling

Tim Colling — Thu, 02 Jul 2009 05:59:29 +0000

Unit testing! Test harnesses! With those two tools, the process becomes much more predictable!

By: Jim T.

Jim T. — Wed, 24 Jun 2009 21:10:51 +0000

I call it the ,McDonalds hamburger syndrome. You can make a Hamburger 90 % correct….lose a pickle, put only 3/4 a tomatoe on it, etc…90 % right and people will pay for and Eat it.
But a Software Program 99 % right….isn’t ANY good…and will not Run or work until its 100 %.