Tag: technology

Categories
Leadership

Tech Debt

Broken Windows in a Wall
Photo by Tara Evans on Unsplash

Software Engineers talk about Tech Debt all the time, but other than it being a bad thing, they don’t often stop to explain why it’s bad, or why they are going to spend so much time fixing it rather than doing something valuable.

Martin Fowler has some excellent resources that explain this in the words of software systems, choosing to prefer ‘cruft‘ more so than debt. It’s a really strong approach. Debt means different things to different people. In business, debt can be a good thing! It lets you do more now. You claim some of the market, or you grow, and you pay back the debt from excess profits you’ve made. Overall it costs less to take the debt.

Sometimes we squint a bit in software world, take some shortcuts and call it that good kind of debt. Then we take a few more ‘quick wins’, then a few more, until we end up throwing our hands in the air and the Engineers are calling for a re-write.

Instead of that, when we think on ‘cruft’, we can take a more healthy approach. We build the smallest thing we can to service the needs of today. We build it well, and we can change it quickly. Cruft builds up as we learn more, honing what we have to the real needs of the world. Assumptions we made in the past turn out not to be valid, and we need to correct.

By cleaning up as we go we keep on top of things, keep moving fast and keep driving value at pace. If we understand this as cruft not debt, then it’s in the interest of every stakeholder to stay on top of it as we keep going fast by fixing as we go.

Bringing this back to a real world example, I’m busy looking at the windows in my house. Lovely wooden frames, original with real craft put into their creation. However, they’ve not been well maintained. Rather than a quick sand and paint every few years they have been left in the weather for years on end. Patched and painted without repair, then patched on top again.

They look OK from a distance. You could patch and paint again but it’d only cover a couple of years until you need to go again. That’s paying 5x the usual maintenance cost.

You could strip them back fully, repair everything and get into the standard maintenance cycle. That’ll cost most of what a new set will set you back, and they’ll still have some of the neglect baked in.

So you have to take them out, take out some of the supporting sills and lintels that have also been neglected and start again, a big expense but necessary to get a high quality outcome.

Back to software, and you see the same cycle. Build your maintenance in to your plans, fix as you go and don’t let the jobs get away from you. If you have to get something live quickly, then recognise that and double down on improving that area in the near future. Fix a quick fix properly, or it becomes a load bearing layer of your solution.

Don’t accept bad debt and you’ll drive more value faster for longer!

Categories
Leadership

Work the Problem

Technologists love solving problems, it’s one of the defining characteristics that pulls people into the world of high-tech. When this desire is put towards the right ends, then it’s a powerful force for good. There are some tools and techniques that can keep you on this path, and a few traps to watch out for.

First up, be clear what the true problem is you are trying to solve. Understand what the issue is, consider who is impacted now and what will change once it’s solved. Look at the value in the solution, the costs involved in solving it and the opportunity cost of targeting this vs something else.

Taking time to build this understanding gives a proper frame to the problem. It’ll prevent a couple of the traditional mistakes we can make, things like automating the existing bad process, or only providing benefit to the noisy stakeholders who are demanding a solution right now.

Now, step away from pure technical solutions. If you stay fully in the world of software and hardware, you’ll find you default to solving all problems by just writing code. The longer you do this, the easier it is to drift away from your customers, until all you care about is the minor version of the tech stack and wringing out another micro performance update. You’ll probably place too much weight on getting rid of old software just because it’s built in a slightly outdated way, rather than moving on because it’s no longer serving a purpose.

So, look over the problem again. If you aren’t selling enough of a widget, then don’t immediately jump on updating a feature. Maybe you are not marketing it to the right people, or your copy is out of date. Is it a complex product that has a sales funnel? Can you optimise that? Are people using it correctly or is it too complex? Maybe the right solution is taking away features rather than adding more?

When you look up beyond the purely technical, you increase the overall impact you are able to have. Work with the cross-functional experts in all the disciplines relevant to the problem and you’ll always come up with a better solution. You can be confident that when you break out the development environment and start cutting code that you’ve worked the problem and that a technical solution is the right one.

Categories
AWS Cloud Computing System Design

Architecture Qualifications

I was recently asked about Software Architecture qualifications by a reader to the blog, and I’m keen to share my advice a bit more widely.

They are an experienced developer, looking to take a step away from being an individual contributor, to become a design and system implementation influencer. They wanted to know my thoughts about TOGAF, and how useful the qualification had been in my own progression.

My advice assumes that you’ve already decided that a certification or formal course of study is the right way for you to go on your next learning step. If you are a proponent of the 70/20/10 model, then this is very much covering what you should do with your 10% time. So, without further ado, let’s get into the nitty-gritty of the possible options.

TOGAF was an interesting course of study, but I really feel it’s got a very narrow range of applications. I believe it’s only relevant for a very small number of extremely large organisations. It’s main focus was around the creation and maintenance of a large architecture practice in an enterprise, which is well away from the day to day of designing and developing systems.

If you are looking at a progression path from individual contributor to technical leader, then I’d strongly advise your favourite flavour of cloud certifications. I use AWS at the moment, and there’s a Solutions Architect track that’s really good. There are similar Microsoft paths for Azure, or Google ones for their cloud.

ITIL is possibly a useful direction, but that does tend more to hardware and processes, so might be less useful if you are aiming to design and create new systems, as opposed to running existing systems stably and efficiently.

If you are thinking modern companies, strong agile approaches and staying close to the day-to-day implementation of your designs, then the Cloud route is my number 1 suggestion, and there’s a lot of great supporting courses out there to aid your studies!

Categories
AWS Cloud Computing

AWS Cloud Practitioner

In a brief break from focusing on Leadership books, I’ve been brushing up my technical skills and reviewing some training material from AWS.

Amazon’s cloud offerings are many and varied, and they can be daunting for anyone unfamiliar with the basic concepts. The AWS Cloud Practitioner certification provides a grounding in these core concepts, and is suitable for anyone who has to interact with AWS in a professional capacity.

The AWS provided training consists of around 7 hours of content, covering the basic principles of the cloud, outlining some core AWS services and then covers security, design and pricing. It’s broken down into short videos with knowledge checks following each section. It’s easy to consume and easy to understand.

The certification is a single multiple choice exam, consisting of 60 questions with 90 minutes to complete. I also took the practice exam, which was 25 questions long, but I’d advise doing this a few days before your scheduled exam as the the results are not always ready immediately.

Once you’ve passed the exam, you get access to a digital badge that you can share to display your credentials.

As is often the case with these kinds of certifications, the value is in the initial training, which I would recommend for anyone who wants to learn the difference between EC2 and S3, and why either matters. The exam and certification are an additional extra, nice for hte validation but not fundamentally required.

This is a stepping stone for other more involved certifications, but I’d say it’s not required. An experienced developer could skip this and move straight to the associate level exams without missing much, whereas a product owner, scrum master or other non-technical person may really find benefit at the practitioner level.