Posts tagged Business
Recently I’ve been involved in a lot of discussions regarding Technical Debt. A lot of the discussions boil down to “we have a mountain of tech debt, how can we pay it off?”. To me this is fundamentally the incorrect way of looking at the problem and the terminology is partly to blame. When we think of debt it’s something that you can pay off and if you don’t go into debt again you never have to worry about it. But there isn’t a system out there that doesn’t have some Technical Debt.
The most pristinely architected, well written, accurately commented, OOP, SOLID, unit tested code now, will in the future be some form of tech debt, either because the code was written with incorrect assumptions, wasn’t maintained, or the knowledge about it was lost and people became afraid to touch it.
Technical Debt is the wrong term, we should be talking and thinking about Preventative Code Maintenance.
If you think about it the products your company is creating is somewhat similar to National Infrastructure. The ‘sexy and sizzle’ parts of both Infrastructure and Code is the creation of new: new features, new products, etc. What doesn’t generate sizzle? Routine maintenance.
Take a look at this video from John Oliver’s Last Week Tonight about Infrastructure (somewhat NSFW).
The issue is you can’t take an “all or nothing” approach to Preventative Code Maintenance. For example you can’t just do one off, large projects to fix issues “the Technical Debt style” nor can you do all small incremental updates, a “Scout Coding approach”.
Preventative Code Maintenance can help catch and correct issues before they get too big. But teams need to be empowered to tackle these issues when they are small, and manageable. Far too often an issue is just tagged as a ‘Tech Debt’ item and pushed to the backlog, where it is constantly push down and deprioritized until the issue is so large the business is unwilling or unable to take the issue on, until that is the issue starts impacting the business.
But before an issue ever starts impacting production there is a time when it can be mitigated. But at the time the issue could be deemed too small or too unimportant to take care of.
Preventative Code Maintenance “PCM” should be the #3 priority permanently on your board
Why #3? Well we do need features and enhancements, it’s important to our customers and to sales. There usually is an important bug or other non-preventative issue that needs taken care of. But always plan and prioritize taking care of preventative issues when they are small, unassuming and seemingly unimportant is far more cost effective then waiting till they are costing you business. In your scheme you should block enough weight for the Preventative Code Maintenance task as well. Use Tee-shirt sizes? PCM is always an L, Fibonacci? Put it at the higher end of your scale, (5 for the places I’ve worked). Doing 2 week sprints and just use days? Give it 2 days.
At first you may only be able to get one PCM done or maybe partially done. But as time goes on you will be able to get more and more done in that time frame. Given time and effort it will end up being truly preventative. You can obviously do more Code Maintenance then just the ones you can fit into the one item, but the goal is to always be working on some PCM.
Don’t delay maintenance until it’s costing you business or customers and reached the point where it most likely is expensive and painful to tackle. Be proactive and tackle the issues when they are small, cheap and easy to fix.
If you’re a First Responder or know one check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations.
I’ve been in technology on both the IT side of the house and the Development side of the house now for over 15 years. I’ve seen projects, transitions, major efforts, etc fail gloriously, succeed spectacularly, clutch success from certain defat and everything in between.
I’ve heard a lot about “Failing Fast”. It’s a lean startup principal and is the foundation for a lot of how bootstrappers work. But I’ve seen it more and more in the agile community as well. Companies pick up the “Fail Fast” mantra and repeat it.
Out of all the companies I’ve seen that say they practice “Failing Fast” very few actually do, why because failing fast is hard, very hard. In the world of startup success is only possible because of failure and lots of failure. Slowly people are realizing that for all the Google’s and Facebook’s success stories there are thousands of failures that they stood upon. But for all the good that can come out of failure (I’ve always said I learn far more from my failures then my successes) there are some very real bad parts to it.
First off there is a very real emotional consequence to failure, it sucks, it hurts and it makes you feel like crap. Your ego get’s bruised and you start to question a lot of things, a deep level of critical introspection is never fun. Secondly there is the expenditure of capital (it can be money, reputation, favors or even political capital) that was expended on the failed endeavor that may never be recovered. Next you have the wasted time, resources, brain power and goodwill that all take a hit. If you’ve had 5 people working full time on a project for 6 months, that is a lot of time and effort that they pumped into something that nothing may be salvageable.
Nobody wants to back a failure, especially when they were responsible for pitching or proposing it in the first place. Their ego is on the line when that happens, and it obviously will have an impact on decisions and ongoing evaluation. Finally we all believe at our core that we can accomplish anything, meet any goal or be the single person that can save a project. We all want to be the hero, and how better to be one then to save that ailing project single handily.
Failure can come in many forms, it could be a failure to deliver, failure to deliver on time and on budget or that success just cost too much in the way of relationships, lost personnel, feelings and other items that are hidden from the balance sheet. So yes, even your success could be a failure if you look a little deeper.
So with everything stacked against failure is it any wonder we rarely see a fast failure, especially one with any magnitude? We’ve all done spikes, tested a market and decided “Nah, not going to work” but those are easy and cheep failures. What about a system re-write, where it requires a team months to just get the ball rolling? Do you just call it quits at the first obstacle?
It’s easy when a project fails due to one big cut. The problem that just take the head clean off. You can look at it and say “We failed because of this one big thing and maybe a bunch of smaller ones”. But what about the failure due to a thousand paper cuts? Our tendency is to find a solution, put a band aid on the cut, and keep moving, we end up doing that so much and so often that we forget about all the cuts until it’s too late. This is where “Failing Fast” comes into play, stopping the endeavor before you’ve bleed out.
But it’s hard, you feel like you can’t go to your boss or stakeholders and say “This project is failing because of these little issue”. Their response will be “well those are minor and we can work around them, a new design, reduced requirements, more resources, etc”. But resist the urge to throw ‘more’ at it and analyze why and how it’s starting to fail. It’s easier to do 3 months into a large project, then a year in.
I always have a bottle of Macallan 10 on standby for my big failures, it helps with the emotional aspect.
In 2009 Simon Sinek filmed a Ted Talk entitled “How great leaders inspire action”. It’s a great Ted talk and I recommend watching it. The meat and potatoes of the talk are this “Successful companies and leaders know WHY they do what they do before the how and what of it”
But why is the “WHY” of what you do important? I’m sure there are far more companies out there that only really know the How and What of their business verses the ones that know the “WHY”.
I only recently watched Simon’s Ted talk during my annual Wildland Firefighting recertification and it got me thinking. For my company, Resgrid, I can give you the WHY of my company in 3 words “Empowering First Responders”. This drives why the company exists, why I have a free plan when pretty much every SaaS book/blog/talk/course out there says not to and why we’ve been adding new features while keeping the cost as low as possible.
The “WHY” of your company (or you) does what it does gives you purpose, direction and principals. If it is well stated, simple and communicated it will be far easier to get all your employees, partners, etc all moving in the same direction toward the same goal.
The “HOW” and “WHAT” of you company will change over time, but the “WHY” never should. You may start out with one direction say creating mobile applications then start delivering a SaaS solution. Your “WHAT” will also change, you may pivot, change markets or start making hardware instead of software. But your “WHY” is your rock, your north star.
Companies that don’t know their “WHY” end up thinking that their WHAT and HOW are what matters. They let their technology stack define their identify or their market. Your “WHY” can define your market or define your company philosophy. If your only in business to make money that’s ok too, but that’s more difficult to communicate to your customers.
Communicate up and down your company structure ensuring everyone is on the same page. Share it with your customers and perspective customers. People like knowing why something the way it is and it will endear them to your company and it’s brand.
Resgrid is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).