Archive for January, 2011

A Hidden Root Cause Problem with Software Products

Friday, January 21st, 2011
“The worst programs are the ones where the programmers doing the original work don’t lay a solid foundation, and then they’re not involved in the program in the future”. – Bill Gates

Have you ever looked back at something you wrote or created years later and wished you could do it all over again?  While you may be proud of what you originally did, most of the times you can think of many things you would do differently.  Most software architects and developers can relate to this.

While the desire to rework things you’ve already done exists in most facets of business (or even life in general), the issue is magnified with software.  There are several reasons for this:

  • First, a significant amount of time lapses from creation to completion. Beyond initial completion of the software, the problem gets worse over its lifespan.
  • Typically, the first things written are the foundational items.
    • There is usually pressure to “see something” working.
    • Technology choices, architecture patterns, coding standards, and the exact way that certain things will operate are all decided in the first few months.
    • You may or may not have the right people making these decisions. The wrong people will create problems that will be with you forever. The right people
      are sometimes too in touch with the latest and greatest technologies and philosophies and also are probably their own biggest critics in the end.
    • Decisions are sometimes also too much of a function of the times. With the rapid change in technology, over any 5-10 year period, this could mean big differences between how it was done and how it should be done “today.”
  • Business Needs Change
    • It’s not practical to consider all future potential business needs up front, but in most cases throughout the life of a software product, the requirements will change
    • Many times, the changes of requirements are big enough that require sweeping global changes to the software and it is very costly and risky.

The irony is that the compounding of this problem over the years is usually the thing that ends the life of a software product, but there’s rarely a time to justify going back and changing it.  Having managed software products and divisions at both small and large companies, the one thing that is a common is that there is more work in the backlog than can ever get done with the budgets and schedules.

If I had a nickel for every time a developer came to me and said that they wanted to make some global change to the system because it was the right thing to do, I’d have a lot of nickels.  95 times out of 100, their ideas for changes would make the product better.  Unfortunately because of the circumstances, 90 out of those 95 times I couldn’t justify doing what they wanted to do.  The costs of making those global changes are enormous.  The risks to customers, sales, and internal schedules are even worse.  The further along the product is in its lifecycle, the higher the cost and risk.  In the rare event that we could make a case for something, the cost and time had a big impact and it ended up being so disruptive to the product that only future customers could benefit from it (i.e. the already impractical notion of an upgrade became impossible).

The argument that most good architects and developers make is “that’s why we need to get it right the first time” – hard to argue with that.  Unfortunately, that sometimes leads to the old “analysis paralysis” and it’s still unlikely that you won’t be looking at it a few years later with many things you wish were different.

I’ve had the good fortune (and pretty rare distinction) of being part of creating several new software products from scratch.  While there are things that you learn on each one that you apply to the next, you still fall into the trap of continuously wanting to rewrite portions of it.

In my latest endeavor, I’ve tried to tackle this problem head-on.  We’ve architected things in such a way where every piece of code is designed to be replaceable (and backward compatible) in a very cost/time efficient way (largely through built-in automation).  We have a small team whose single focus is to constantly look at the code, design patterns, and technology choices and rapidly make those sweeping changes.  In fact, many of those ubiquitous changes to the actual code can be made through external configuration.  This approach provides a pretty practical solution to this problem that seems to have no real solution.

I’ll write more detail about our solution for this later, but wanted to get something out there to see if others have closely observed this same pattern/problem and/or if others have found solutions that don’t require a lot of compromise or a lot of money.

Tom Famularo



Thursday, January 6th, 2011

It’s that time of year again.  Have you made your New Year’s resolution?   The practice gets a lot of attention – but it’s always in the context of the individual.   Can’t companies make resolutions?  Yes, I’m aware that business entities operate differently than individuals but surely they can join in on the fun.  Not all changes need to come from upper management.  Generally speaking, the smaller your company the easier it is to affect change in your workplace.  But even those working in large corporations can take it upon themselves to make improvements.

I’ve collected some of the most popular resolutions to see how they can be applied to companies in ways that do not require a massive company wide reorganization or even managerial responsibilities.

Lose Weight

Ah, perhaps the most popular resolution of all-time.  The company equivalent: trim the fat, that which serves no purpose.  Ditch what is rather useless and replace with something new.  It could be a copier, a server, or an outdated version of pre-packaged software.

Manage Stress

Individuals can become stressed, and so can departments.   Is a shortage of developers causing problems?   Are people happy with the furniture, lighting, and seating arrangements?  Does your vacation policy encourage employees to take time off?  There are dozens of ways to reduce stress in the office place, and quite often taking action increases productivity.

Take a Trip

Is there a client you’ve neglected to visit?  Perhaps some off-shore folks would benefit from a trip to the US – or maybe a flight in the other direction for an on-shore resource is in order.  Upper management won’t necessarily know if there’d be benefit in people from different locations coming together.  The employees generally do know (or know first).


Does your company give back to the community in some way?  Perhaps it’s time for another blood drive, a scholarship program, or a community service initiative.  This is most definitely something any employee can drive – it need not come from the top.

Pay off Debt

Take action on paying off technical debt – the obligation that a software organization incurs when it chooses a design or approach that’s expedient in the short term but increases complexity and is more costly in the long term.  Every software organization has it.  You can pay now, or pay later.  Pay now.  While large endeavors do require budget, it can be tackled in ways that allow employees to slowly refactor that which they understand well.

Get a Better Education

Does your workforce know what it needs to know?  Are you cross-training?  If there’s room in the budget for formal training, encourage employees to apply.  And if there isn’t, having employees conduct training at lunch time costs virtually nothing.  Documentation, while not a complete substitute for formal or informal training, is often lacking.  Stressing its importance and demanding solid write-ups almost always pays off in the long run.

Quit Smoking

More generically, kick a bad habit.  Individuals have bad habits of all sorts, as do workplaces.  What bad habits can you find in your office?  Meetings, in general, are often thought of as time wasters.  Do your meetings start on time or do people stroll in 5 minutes after the designated start times?  Are people dialing into conference calls while driving or from locations where it’s difficult to give undivided attention?  Is there a designated scribe who types up the notes for distribution to the participants and other interested in the topic?  Do people listed as optional consider themselves optional?  There are plenty of ways to make meetings more productive.

Take a look around and you’ll see there is room for improvement everywhere – not just in your personal life, and not just in your own work life, but in the workplace.  Everyone from the CEO down can take the initiative to better an organization.  Are there any resolutions you’d like your company to make this year?

Jim Buckridge