Friday, April 16, 2010

The Three Dimensional Graph of Choice

I constantly hear people telling me they have to have something done a particular way.  Its this way or it doesn't work.  Black or white.

Why do the religious nut jobs seem to insist that the world is black or white?  You are either interested in quality or you are interesting in making money.  Why not both?  Why not a sliding scale of quality based on the deliverable you are building.

When is good good enough?

Building great software involves thinking about and designing practices that support building software the way YOU need to build software.  Not the way your cousin does it @ tweeter.com down the street.  Tweeter.com has 8000 servers and monkeys as customers.  You do not.

Processes like QA, development - controls on how you build software should be evaluated based on a 3 dimensional graph of # of users, complexity and Lines of Code (LOC).


Why the three dimension graph?  Its an easy way to visualize a sliding scale of control.  Developing something just for yourself?  Avoid QA all together - I know I write bug-free code so why not let myself enjoy the fruits of my labor sooner?

Lets talk a bit about the three dimensions because its important to understand why each of them plays a critical role in helping you decide what level of process or control you need to develop your software.


Lines of Code (LOC)
Developers hate this measurement.  It makes them feel like what they are developing can be measured like a widget off of an assembly line.  The reality of the world is that as good or bad as it is, it is a measurement.  Last I checked there was no way to measure "How beautiful" your code is.

Need a new feature on your website?  Well that's just 1,200 lines of code - can I have it next week?  Why then is it important?  It is important because it is a neutral way to judge the size of what you are building.  I constantly try to get my team to consider building applications without writing code?  Why?  If the world existed of packaged software that I didn't write a single line of code for I would never have to support the codebase.  Supporting applications from a development perspective is arguably the single most expensive thing you can do in IT.

Think about this example for a minute:

You spend 20 hours writing a feature in a legacy application.  It goes through QA, you bug fix and all out the door you've spent 30 hours of time building this feature.  It goes into production, your users love it - champagne bottles pop and you all drink to your success.

Six months go by and someone needs a change to your feature.  The developer who built the feature is not available - he's tied up on another project, he left the company for a job @ tweeter.com, whatever.  Maintenance is a crappy job in any profession and building software is no exception.  So its not your best and brightest you put on maintenance duty - Its Steve - you know the guy who is smart enough to load the development tools and do a little poking around but not skilled or seasoned enough to be designing your latest "double the business" idea.  Rock stars don't get invented so every shop has their promising interns, new hires, etc. hanging around to learn from the Rock stars and hopefully one day be one of them.

Steve doesn't know your legacy app so he takes a few hours to get the app loaded and understand the basics of how it works.  He then starts to explore the feature you wrote.  He has no idea why you implemented it the way you did and proceeds to determine that because you used a "double helix hash" method of storing key values he can't fathom the change he is being requested to make being able to be done that way.  So he decides rather than to re-factor the code it would be faster and simpler for him to just rewrite it from scratch.  Only this time he decides that he going to make it more extensible, add comments and make it easier for the poor developer who gets asked in 6 months to make another change to actually make their change without rewriting the code.

50 hours into Steve's rewrite Paul, Steve's manager, finds out he has been taking 5 times as long to write the change as Steve estimated and tells Steve he has 1 day to finish it up.  Steve hurries through the last pieces of his rewrite, leaves out some comments and puts in some very cryptic but functional code to accomplish the change.  It goes through QA and 70 hours have gone by and its finally in production.  Six months later someone finds a defect that Steve's code introduced and the whole thing has to be "fixed" again.

How many lines of code are you current supporting?  How quickly do maintenance issues get addressed?

# of Users
This is an easy metric but one that often gets overlooked.  Everyone assumes that when they design software for the web that they have to design the software for the 1.1 Billion people on the planet that have a reliable internet connection.  Its easy to dream about millions of simultaneous users from around the globe using your bright shiny software to the delight of everyone at your company or organization.  Its also easy to get to a real number.  Do you have multiple languages on your website?  Getting rid of the unicode and translation requirements can drastically simplify development.  Won't ever need a simplified Chinese version of your website?  Then don't design like you might some day.  How many people visit your website today?  What is your Alexa traffic rank?  Where do they come from?  Thinking about the actual use patterns of your software will get you a rough order of magnitude for the # of users.  Remember that you are solving a problem not building the next Google or Facebook.  Don't believe me?  Look at sites like BookRags.com  They are the #1 natural search result for many book summaries, etc.  If you deliver value people will use your software.

Complexity
This is a harder one to judge but I can give you a few examples to help you figure out where you sit on the scale.  Is your software going to interface with other systems?  Is it part of a larger technology process?  Does your software need to do some heavy lifting that can't be done with packaged software?  The answers to these questions and more will help you decide if your software is complex or simple.  Don't let your developers bully you into this.  9 times out of 10 in  my experience developers when left to their own devices will over engineer a solution and increase the complexity unnecessarily.  You have to continue to push people to understand what exact problem they are trying to solve and like anything in Technology there are 20 ways to do it.  Engineers will also try to find the most complex - its their nature to do this.  Avoid it at all costs.

So we have this 3D graph to help us make good decisions about how formal or informal our software development process should be.  So what does it typically look like for IT shops?  Based on my experience, which is arguably limited to just 8 different companies across 4 different industries, it looks a lot like this:


So what types of things look different?  Well imagine you are developing software for a Hospital and that your software could ultimately determine if a patient lives or dies?  What if you are building software for the Space Shuttle?  What controls should you have in place to ensure everything works as designed?  I like to use the Space Shuttle because its likely still one of the more complex pieces of software there is but has a low number of users and a decent number of lines of code.  Think about the controls required to produce the following, courtesy of an article in Fast Company:

"But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."


 Unfortuanately we typically design our internal software like its going to run the Space shuttle.  It has to be extensible says the business.  It has to be maintanable says IT.  How will we keep the data in sync Finance asks?  All these things create anxiety and angst with software developers until you end up with the 3D graph of choice looking like this:



Before this happens to you, take a moment to think about the three axes i've written about above.  This isn't rocket science folks - well that is unless you are one of the 260 people in the world that design Space Shuttle software.  For the rest of us getting the framework and process right may just get you to a better place.

-Kris



Friday, April 9, 2010

If you want to create jobs incent people to create businesses

Paul has a great post out today that talks about how job growth is inevitable for new small business.  Interestingly he uses the Drunkard's walk (or should it be stumble) to illustrate that it is simply inevitable for young companies to provide job growth.

"Young companies are the single-celled paramecia of the economic world: at t=0 they stand at the bar wall facing the gutter. They can’t lose jobs because they haven’t created any yet. All they can do initially, other than fail, is stagger away from the zero employment wall."

It changes the way you think about how to add job growth into the mix.

-Kris