When is your next deadline?

A great software process won't guarantee a good result, but a poor process sets you on the road to failure

Out of Control Projects


If you hang around the computer business long enough, you'll see an out-of-control project:  blown deadlines, buggy software, escalating costs, and no end in sight.   Your most dedicated staff members are working 80 hours a week, wandering around the office like skittish zombies.  Sometimes these failures are due to poor project management, but they're often due to a team that's ignoring the fundamentals.

Tools, Tools, Tools


Would you trust a plumber that showed up with only a pipe wrench and a hammer?  Would you take your car to a mechanic who didn't have a lift?  Would you hire a landscaper who only had a string trimmer?  Of course not.  Professionals bring the right tools for the job.

Here's a checklist of tools that you need for any software project, no matter how big:
If you don't have all four of these tools in place, stop right now and start making plans to get them.  These tools need not be expensive.  In fact, the best tools for this kind of work are usually free!  You'll have to pay for setup, but they'll pay dividends within days of installation.

On larger projects (anything over $50,000 in custom software development), there are more tools that can make your life much easier.
The usefulness of any tool is directly related to the knowlege of the person using the tool.  An MRI machine is a great tool for a radiologist, but to a layperson, it's just a big metal donut.  I can help your organization find the most cost-effective tools, set them up, and give your team on-the-job training in how to use them.

Methodologies

The pseudo-word "methodology" is made up of two parts.  "Method" is a known way of accomplishing a goal, "ology" just usually means "expensive and inflexible."   There's a whole alphabet soup of methodologies out there:  SDLC, RUP, XP, RAD, JAD and a few others.  Let me let you in on a few big secrets:

Big Secret #1:  Most methodologies are, at their core, the same.  They usually consist of four steps:  "ask", "think", "code", and "test".  They vary in the techniques that they use for each step, and how many times they run through the series of steps before delivering a system.

Big Secret #2:  Methodologies are like bellybuttons.  Everybody has one (and for good reason).  Some are very formal, written down in big books with checklists, forms and required signatures.  Some are completely casual, and are maintained as a form of "tribal knowledge."

Methodologies are all about managing risk.  The key to finding a methodology that works for your organization is to match the methodology's risk management strategy with your organzation's risk management strategy.  I know how the different methodologies work, and I can find one that matches your firm.

Quality Assurance


Ever had this happen to you?  The programming team thinks everything is going along swimmingly.  They're 80% complete, on-schedule and on-budget.  Then they let you test-drive the system, and everything blows up.  Bug after bug after bug appears.  The system gives the wrong answers, crashes, or just behaves unpredictably.   Every bug fix seems to introduce two more.  Whose fault is this?

If the problem is that the system is giving the wrong answers, then the problem lies with the people who formulated the requirements.  When you are working on requirements, it is important to constantly ask, "When will I trust this new system?"  Put another way, "How can the programming team prove that the system works?"  For a system that calculates commissions, the answer might be "When total sales reported by the commissions system matches total sales reported by the general ledger."  For an accounting system, it might be "When the assets equal the liabilities."

The key to these requirements is that they are objective:  the numbers match or they don't.  This kind of clarity during the requirements phase will help your programming team understand the underlying problem.  Give your team examples - especially tricky ones - so that they will find problems before you do.  Don't forget other areas of trust, like performance ("When the system can process 10,000 transactions per day") and reliability ("When the system can run under load for a week without crashing).

If the problem is that the system is crashing (or otherwise just fails badly), then the problem is with your programming team.  Most programmers keep working on a program until they can't find anything wrong with it.  That's backwards.  Programmers need to think about how they will test their code first, then write their tests, and then and only then should they start coding.

Here's a thought.  Testing programs is boring.  It's tedious, repetetive, and requires a keen sense of detail.   Hmm, what's a good way of solving tedious, repetetive, detail-oriented tasks?  Could it be a computer program?  Yes, and that is one of the best practices that your programmers can take up.  Programmers should be writing a set of test programs to go with every "real" program they write.  It seems like so much overhead when you're doing it, but it gives you the ability to run your tests over and over, essentially cost-free.  Having test programs in place gives you an "early warning system" that tells programmers (and managers) when things are going off-track.

A final thought on QA:  pobody's nerfect.  No matter how detailed the requirements, no matter how many test harnesses you build, you're going to learn things while you're developing your system.  That's just the way the world is.  I can help you realize when your requirements don't have enough trust/proof points in them, I can show your programmers how to use the latest techniques to write test harnesses quickly and easily, and I can help managers understand that sometimes, the world is an imperfect place.
-->