What Should Software Developers Be Doing .....and Why Aren't They Doing It?

What should software developers be doing? It’s not a trick question and in general a pretty obvious answer, developing software.  I am sure you are thinking no kidding, but many organizations that depend on development to drive innovation, differentiation, revenue and ultimately profit have common “productivity leaks” preventing developers from doing just that.  Most of us, particularly software developers, that have gone into emerging technology, have done so because we are adaptable, creative and like to solve difficult problems with technology.  If we make deploying, managing and monitoring the infrastructure the difficult problem to solve, developers can and will spend the majority of their time working feverishly on maintaining infrastructure, and little time on using it for its intended purposes, developing and deploying software.  

If you have not experienced this and feel like offering someone a chance to vent, take a minute (it is likely to end up being a couple of hours) and ask a product manager, engineering manager or tech executive if, even when the scope and approach are well defined, feature output has ever been slower than needed or anticipated.  I am guessing that it won’t be hard for you to find yeses, accompanied by explicatives, heavy sighs and probably some uncontrollable laughter. You will hear examples of skilled developers, working hard, working early, working late, working happily, checking off tasks and still missing timelines.

The last decade has seen accelerating adoption of many things that have dramatically improved development including, public clouds, private clouds, Agile methodologies, DevOps infrastructure(infrastructure as code), behavior driven design(BDD), gherkin acceptance criteria, automated testing, continuous integration, etc.  All of which have made it faster and less costly to bring products to market than at any time in history, but many organizations continue to battle the issue of activity severely outpacing achievement.

Not always, but many times, if you look under the covers, what you will discover is that software dev. organizations are leaking productivity into infrastructure management.  

So you’re thinking, that’s interesting but what’s the plan of attack?  

1 - Take a step back

First you need to be able to recognize the problem.  Missing schedules and lots of hard work without releasing functionality are clear signs, but they are lagging indicators, almost like looking for the pound of cure rather than the ounce of prevention.  Some warning signs that should be a clear tip-off include hearing phrases from developers like: “I have an open ticket with IT / DevOps to build [fill in the blank]”, “We are going to take some sprints to work on plumbing infrastructure”, “We need to work on instrumenting the infrastructure”, “We will complete configuration of the new servers”, “The database has been configured”, “We got the POs for equipment approved” and “We are responding to an outage”.  Essentially anything that sounds like the developers asked for a self-service fuel station and were given oil wells and a refinery.

2 - Think Ergonomics - Fit the infrastructure to your business and not your business to the infrastructure.

When selecting infrastructure it should match your organization and its goals.  It needs to:

• Deliver consistent, predictable, repeatable performance - enabling users to design and make decisions based on data rather than intuition.
• Scale capacity and performance without disruption - enabling growth without slowing innovation.
• Monitor, measure, analyze trend, model and predict - enabling you to plan rather than forcing you to react. Leaning toward system optimization over fault resolution.
• Integrate with your existing management interfaces as well as future ones - meeting current needs and future vision without missing a beat.
• Proactively self heal - letting you know that it is happening and when it is complete
• Enable you to avoid most issues rather than having to react to them - automatically initiating corrective action and notification.

Above all, if it is going to be used by programmers, it needs to be programmable.

3 - Think twice before  pulling out the hammer.

The old saying goes, when your new tool is a hammer, everything looks like a nail. This is not a good thing! It is seldom clear cut but it is important separate culture from infrastructure and do not try to solve one with the other.  Instill in your culture, where you want to go, what you mean by accountability, success criteria and how you are going to go about things.  Your infrastructure should help to unlock the potential of your organization.

4 - It’s chess not checkers

Changes and the resulting improvements, will take goals, strategy, planning and time.  I have found that virtually everyone is in favor of progress, the changes are usually harder to get on board with.  Take things in small achievable chunks, allowing people to get comfortable celebrating some wins.  Moreover, you will give yourself many opportunities and time to adjust your course with less throw-away work. How do you eat an elephant? One byte at a time.

5 - Know which way the possession arrow is pointing

There are offensive and defensive strategies and good reasons for doing each.  If the goal it to continue doing what you have always done, the way you have done it  with some incremental improvements or simply respond to the competition, a defensive strategy for your business and infrastructure may be the answer.  If you are however trying to do what's never been done before and truly innovate, an offensive strategy and a complementary infrastructure are likely in your near future.