Money. It seems to me like it holds an all powerful place with just about everyone.
Those that have tons of it use it to influence those that don’t. Sometimes that influence makes things better. Sometimes it doesn’t. Regardless of whether you think money is the root of all evil, or that you really wish you had more of it (or less of it) there’s one thing I know for sure.
When we write code – one way or another – it’s all about the money.
I know what you’re about to say.
“What about open source that you just flaunted so recently?”.
I promise you, even that’s about money – just in slightly less obvious ways. I’ll get to that, but in a later post in this series about “value”.
I have lots to say on this subject. Having been through business school, I know all about balance sheets, income statements, and cash flows. It will take more than one article on the subject – so this is what I want to focus it on today:
How do software engineers deliver more quality value faster?
This question has a huge amount of inherent “loadedness” in it. Yes, I just made up that word. But it seems appropriate, don't you think?
Interesting how so much can come out of a handful of words, isn’t it?
I’ll summarize it, and then dive in.
Deliver: Our code is worthless to our business if it doesn’t go into production or inform what went into production.
Quality: Value can’t be delivered if it’s not delivered well. Quality means that we always get it right when it goes to production – so that the value delivered wows the client.
Value: Quality over quantity. We want to always deliver more than we did before (by improving our velocity) but never by compromising quality. Value comes from one important thing – measurability. We measure quality, and we measure the results of our hypothesis that our code as written solves the problem it’s supposed to solve.
More/Faster: When we deliver more, faster value – what does that mean? We don’t compromise on quality. What we do is find ways to deliver the right things, as quickly as we can. And always get better at getting faster – the core tenet of continuous improvement.
Production or Bust
When was the last time you used an application labeled “alpha”?
I’ve done it, but not very often, and only because I was especially interested in helping the team vet the direction of their software.
In general, we can’t get really valuable feedback about the features and concepts in our software until it gets to production. Whether you do this by incorporating feature toggles, A/B testing, or other patterns that allow us to get features in front of users – the point is that we need our users to see stuff and see it as soon as possible.
Like a Real Estate Developer
So, why do I claim that getting software to production has so much inherent weight? I’ll use the concept of real estate development as a pretty straight metaphor for software development in this case.
When a land developer buys a plot, they have immediately began losing money on their investment. Until they finish building the house or the office building on it that they plan on selling or leasing, this investment loses value over time. Until they can begin reaping revenues from this property, it’s only an expense. That’s why real estate project managers get paid tons of money. For each day of project time they save it’s huge amounts of potential revenue gained.
6 Months is WAY Too Long
Extrapolate this into software development.
If you and the team take 6 months to deliver a feature set into production, that’s a pretty big expense. I’ll be slightly concrete here. Let’s say you’re on a good scrum team of 5 people, each earning $50 an hour. So, for each hour you’re working the expense to the company is $250. 6 “work-months” equivocates to roughly 25 work weeks.
Assuming 40 hours a week X 25 weeks X $250 = $250,000 invested in this feature set by your company. Staggering when you think of it that way, isn’t it?
Now, let’s say optimistically that this 6 months managed to get the software all the way from concept to production. And let’s say that you’ve been able to reasonably prove it will improve bottom line revenues by $10,000 a week. That means that the feature set you’ve written won’t be profitable for another 25 weeks. 25 weeks X 2 (half for dev time, half for ROI time) and now you’re talking about AN ENTIRE YEAR before your company actually realizes any return on this development effort.
What happens if within that 25 weeks your customers realize that it’s not worth $10000 a week any more, and usage drops off substantially before the full ROI becomes realized.
Because it took 6 months to get the software to production, it’s entirely possible that your company is LOSING MONEY on the development efforts.
Now, I’ve contrived this example to show one possible extreme case – but I’d venture to guess that some of you readers have seen a situation even more expensive for your companies than the one I just made up here.
That’s where things like Scrum and Continuous Delivery really shine. The faster you can get your software to production, the less opportunity cost it sucks out of the company bottom line.
Production Means Profit
So, assuming that we’re really able to get our software to production within the span of a scrum sprint (which I’ll talk about in the 4th post in this series) and that we’re able to do so in a valuable way (with A/B testing, feature toggles, and other neat tricks) what’s left to do in terms of production enrichment?
Like everything we efficiency minded engineers tend to do, getting software to production needs just as much appropriate engineering as the software itself.
Tools like Bamboo and Jenkins really help us to deliver things more automatically and with processes that we can trust and rely on. In fact, lately I’ve been really taken with the Bamboo plug-in for Slack – because I can get this really bright red notice that one of our builds or deployments fails in a place where a good bit of my attention is directed anyway.
That’s the most important point, though. Build and deployment failures have to be actionable items that we can eliminate in an automated way.
Automated Tests Failed
If the build failed because someone’s automated unit/functional/acceptance test didn’t pass, it’s our responsibility to decide the following:
- Does the given test really provide the value we expected it to? Or is it too expensive to keep fixing it every time it fails?
- Fix the test if the value is both obvious and has a reasonable time frame.
This recent tweet by Cory House sums up the idea of value in an automated test nicely:
When to *automate* tests:
1. Too time-consuming to test manually
2. Too complicated to test manually
3. Cost of error > cost of automation
Automated Deployment Failed
Even more actionable than an automated test failure is an automated deployment failure. I firmly believe that configuration management using something like Chef or Puppet combined with deployment management using Bamboo or Jenkins gives us no excuse to keep doing manual intervention steps to deploy our software.
Every part of our environment management should move towards completely eliminating non-deterministic behavior as much as possible. On the spectrum of continuous delivery, one of the lowest hanging fruits we can grasp is the automation of our deployment steps.
Repeat the same steps each deployment, every time, with a deployment script. Plug that script into a continuous delivery management tool. And then watch for it to turn red and react immediately when it does. Because then you don’t ever have to worry about getting code to the right place via builds. You only have to worry about code management.
Software Producers
While you’ll find plenty of discussion around the semantics of whether we’re software engineers, or software programmers, or anything else you think people want to call us – one thing is unarguable.
We are software producers.
Production. As in deployed. As in the customers can see it.
So get it to production, and then follow up on my next article, about how we do it with the most proper respect for quality.
If you deploy it and it sucks, that’s no better than leaving it undeployed.
Manage The Code. Automate The Process
Everything we do to get code in production should make it so we don’t have to think about the overhead of getting code to production.
We should automate the process of tracking paperwork (like with Jira which has hooks into Bamboo and Bitbucket… because Atlassian) and tracking deployments (with Bamboo triggers, for example).
What that leaves us with is the part of the process engineer should really concentrate on. Moving code using code reviews and pull requests and appropriate branch management to makes sure that the right code goes into the right place at the right time.
If we take the time to automate all of the painful stuff about getting code to production, then we can take the time to verify our code does what our users need it to do by having thoughtful and productive conversation about each line of code.
After all, we should treat every line of code as a business decision.