You Want IT When?

I’ve been reading a few essays on blogs that say the aim should be good enough.  It’s hard for me to get excited about good enough.  It’s not very motivating. Think about it.  Can you get excited to get up every morning and say, “I can’t wait to go to work today and do a good enough job?”  How uninspiring?

Picture this.  You are a member of a new project team that is planning to build a new product that competes with Yahoo, Google, and Microsoft.  The manager calls a project kickoff meeting with the software development team.  To motivate and focus the team, he outlines the strategy to the troops.   He exclaims, “I don’t want you to get carried away with aiming for perfection.  Our goal is to develop a good enough product to begin to win market share away from Yahoo, Google, and Microsoft.”  It’s like some Dilbert cartoon. 

I didn’t get into the software business to build good enough products, and I’m pretty sure most people in this business didn’t either.   Could you picture yourself interviewing with a company, and the interviewer says, “Our software teams aim to build good enough products.”  As you shake hands and begin to exit the interview, you ask yourself, “I wonder how many people they hook with that line?”

Think about it.  Has Apple dominated the MP3 space because they decided to build a good enough product?   Has Apple actually aimed to build anything that you would consider good enough?  Is Google dominating the search market because their search is good enough?  Is the huge demand for the WII game console the result of a good enough product decision? 

Who get’s inspired to buy good enough?  What kind of demographic is that?  If you’re aiming to sell your products in the local five and dime store, good enough is all that’s required.  The commercial software market is extremely competitive.  Good enough won’t cut it for very long.

People who advocate good enough contrast it with perfection, but there is another choice: excellence.  Choose to build an excellent product.  Choose to build the best product. Not only will it be good for the bottom line, you will find that you are attracting the best talent in the industry.  Moral is high when individuals and teams are aiming high.  The best talent doesn’t aim to be good enough; they aim to be the best.  Aim to be good enough, and those who aim for excellence will leave your company and your products in the dust.

I’m reminded of an interview I had with a young company for a Software Director role.  They were at point where they were ready to begin rapidly acquiring new customers.  When a new customer signed, there was customization required to have the system operate according to the customer’s demanding requirements.   The turnaround time from signing the new customer and having them productively using the system was approximately four weeks - at least that was the goal. 

(more…)

One of the difficulties I have with the Agile software methodologies and its proponents is that they go to far.  They are often susceptible to hyperbole while hawking their methodology like used car salesmen.   Their embracing of the practice of refactoring is one example of this. Of course, we should refactor, but refactoring isn’t a design methodology,  it isn’t a way to be agile, and it doesn’t help deliver software faster.  Refactoring as advocated by the Agile processes is essentially a design methodology.  A team following Agile arrives at an optimal design and implementation via a series of iterations and refactoring efforts.  Refactoring as a design methodology is incompatible with the Agile goals of delivering faster and accommodating change anytime in the project life-cycle.

(more…)

It finally happened.  It was only a matter of time before the day of reckoning would strike.  Leading up to the crisis, you’d never have known there were clouds forming in the real-estate and credit markets.  Since the stock market crash in 2000, there have been a minority of industry professionals writing about the building crisis.  My favorite has been David Tice at the http://prudentbear.com/ .  He has some great presentations on their web site with data to support his case.   It’s unsurprising how when professionals use metrics, they seem to be ahead of the crowd and more confident in their views.  But that’s a topic for another article.

(more…)

Purpose 

To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules.  Quite the contrary, I don’t support expecting a team to deliver herculean efforts.  It’s an unsustainable model.  However, dates and requirements are often forced upon software teams, and they often have little ability to influence the commitments, both in date and content.  The goal of this series is to outline a model to successfully manage through these challenging circumstances for the benefit of the company, the team, and yourself.

(more…)

Management Approach

I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule.  While the tasks are numbered, they signify a loose priority.  It’s not intended for them to be followed exactly one after the other except for the first two.  The first two are the most important of the tasks, and the approach hinges on the first two for this to be successful.  When you’ve completed the first two tasks you’ve essentially identified your strategy.

(more…)

When I was a high school student I was an avid competitor in the sport of wrestling.  It’s an extremely demanding and punishing sport: requiring extreme stamina, strength, skill, agility, and mental toughness.  You have to have a strong mind to compete successfully in wrestling.  When you’re in the 3rd period of a match, you’re exhausted, and your opponent continues aggressively to push the action, only the tough-minded continue to fight and pull out a win.

Preparation for competition is key and demanding.  Practices are lengthy, exhausting, painful, and mentally draining.  It is common for a wrestler to lose anywhere from 3 to 10 pounds of body weight in a single practice.  Preparation requires discipline to keep with a training and weight loss program.  The diet can drain an athlete mentally having to refrain from the daily temptations of satisfying treats.

(more…)

Did you ever read one of those articles where the writer had instant credibility?  I recently stumbled upon one when I was looking to get my web site indexed on dmoz.org.  The article is titled “Nine Steps to Delivering Defect-Free Software” by Terence M. Colligan.  When I read the article I knew he isn’t just writing about somebody else’s experience because it mirrored my own experiences when I was writing software myself.  In the article he identifies nine traits contributing to defect free code.

(more…)

The Agile software development practices are in their infancy stage as evidenced by the number of variants that are being promoted in popular print and usage today:  Scrum and XP being two popular variants.  Clearly the Agile practices are still evolving, and I believe what will eventually emerge are a set of Agile practices that look awfully familiar to traditional approaches.  The question is, is once the Agile community arrives there, will the conflict cease?

(more…)

Does your final project schedule look identical to the project schedule that you began your release with?  If it does, you either aren’t managing your schedule or you are working on a dead product.  Project Management is predominantly an exercise in change management - so much so that I like to think of them as synonyms for one another. 

There are two primary sources of schedule change.  One source is when the actual productivity doesn’t match the budgets in your work break down structure.  The other source, the more problematic source of change, is when your requirements change.  This article will concentrate on managing changing requirements.

(more…)