Consider the cost or Is it really worth it?

As I type this up, I have no idea whether it will be a short or long one.  I feel like I just walked into my studio and I’m about to freestyle on a subject that’s been eating at me for a couple of months and that is the idea that all “best practice” software development practices must blindly be followed.

Determining the cost of doing business can be done at multiple levels within an organization but I want to focus precisely on the software development aspect of things and speak to my technical brothers and sisters in our beloved community because I fear we’re giving a lot of blanket advice without asking people to determine if doing something is worth it from a business perspective.  Why do I think so?  Well I interview engineers all the time who rattle off a list of best practices believing that they should always be used and they quote thought leaders in our space all the time as a basis for this. If you don’t do practice X, you can’t be agile and I won’t work with you.

Suppose I asked you to build me a boat, you would want (I hope!) to know things such as:

  • Why I need a boat
  • What I would use the boat for
  • How the boat impacts my business
  • Where I would use the boat
  • How quickly I needed the boat
  • How long I would use\need the boat
  • Etc Etc

From these questions, you would understand what type of boat I actually needed e.g. toy boat, canoe or a cruiser and the importance of the boat to my overall strategy.

So why is this is critical?  Because your development process will be shaped based on the type of boat I need.  Granted, there may be some cross-cutting development practices involved regardless of what is being delivered, but as a guy who seen firsthand the development process for houses built from clay as opposed to those built from cement, I’m positive there will be some significant differences.  There just have to be.  The practices are never exactly the same.

So coming back to software development, its important that the development practices we become religious about remain contextual. Saying that all code needs 100% code coverage (for example), just seems irresponsible to me without saying when (if ever) that is most likely to be true.  Another pretty common edict now is that all software development need be test-driven at all levels i.e. both internally and externally.  It is critical that the technology team clearly understands the role the software solution plays as part of the overall business strategy i.e. how it impacts the economic bottom line.

An organizations most strategic technology solutions will have maintenance costs over a period of years (assuming they remain strategic)  so we want to do as much as we can to keep those future costs down.  In these cases, it may be prudent to incur more upfront cost to avoid future expenses.  However, for a utility solution that is just helping an organization meet an immediate but short-term need, we may go a different route.  In fact, we may just throw together something over a weekend and call it done.

Understanding the requirements for a solution goes beyond just determining what needs to delivered.  It includes asking probing questions that lead us to make the right investments on how the solution solution should be developed because we understand its strategic placement within our portfolio of solutions.  Don’t forget, there is always an opportunity cost out there. Make sure it is really worth it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s