Category Archives: Rants

The Five Whys

I’ve recently finished re-reading Lean Start Up and a chapter that has been great to refresh is the Five Whys.

It sounds fairly straight forward – a technique which allows you to perform a root cause analysis. Ask “Why did that happen?” five times, to get to the root cause of the problem.

Asking the five whys sounds simple, but in practice, it is very difficult to find that root problem consistently.

Having been through the processes a few times, I’ve noticed:

  • It is very easy to go off on tangents
  • Not have all the information at hand.
  • People tend to focus on coming up with actions as soon as possible, in an attempt to “solve a problem”, and worse, appease Management / Executives.

In most scenarios, I’ve noticed they are actions to solve symptoms and the problem shows up in other forms down the track. Some key reminders for I’ve use during such a process:

1. A very important part in performing the five whys is to perform the session with everyone involved in the room. No proxies, everyone involved with the issue, client facing, technical staff, everyone. This is critical. Perception and roles missing from the analysis can miss the root problem, or fall short.

2. Ensure someone is identified as running the meeting. They are in charge of moving past the noise, avoid going off track and drilling down.

3. The outcome is not to identify actions, but to identify the root cause.  Managers / Executives should ensure this when actions are presented after the analysis, do the actions address the root cause?

4. Actions can make it feel like you are solving the problem, so typically I prefer to address actions at the end of the session.

A great example outlined in the book was:

  1. A new release broke a key feature for customers. Why? Because a particular server failed.
  2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
  3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
  4. Why didn’t he know? Because he was never trained.
  5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers, because they are “too busy.”

Nicely illustrates the “human problem” behind every technical problem.

Outputs v Outcomes

We know software development industry is focused on solving problems. Customer problems. User problems.

Better, faster, cheaper.

There is a great article in the Harvard Business Review on Outputs v Outcomes:

https://hbr.org/2012/11/its-not-just-semantics-managing-outcomes

Outputs are features.

Outcomes is true value delivered.

We aim for our outputs to deliver outcomes, its treated as an abstraction. The problem in most cases is, development teams treat outputs as the end goal, and build release plans, and sprints on getting that “feature” out.

We don’t talk enough about the problem we’re solving, the outcome we’ve aiming to achieve, and even more so, measure whether we achieved the outcome.

I am not a fan of measures such as “Increased usage”. Thats not an outcome.

An great example I’ve seen in building Recruitment software is Time to fill (TTF). TTF is the time it takes to fill a vacant seat from when the request is made. TTF directly translates to Cost to fill, which is a measurable impact to the company.

For a recruitment team, Time to Fill is THE KPI they are measured on.

So rather than building a feature or product we “think” will improve TTF, measure it, try different ideas, and keep trying until you find something that gets your outcome.

None of this is groundbreaking, all we’re doing is ensuring we connect our problem solvers (product teams / developers) to our users. It is fundamentally Agile.

Contextual Craftsmanship

For many years, I’ve spoken to friends, colleagues, mentors/mentees about craftsmanship and how important it is in Software Development.

As a software developer, it is very easy to agree with. Quality is not negotiable, write your tests first, blah blah blah. We understand how important design patterns, readable, maintainable code is, especially in building sustainable software.

One aspect that I find isn’t spoken about explicitly enough, is Contextual Craftsmanship. We all know there is no silver bullet, and hence I find that craftsmanship is very similiar. There is no correct way to develop, and it depends on what you are doing, and the business context you are in.

A start up context is very different to an enterprise. Code built in a hack-a-thon is very different to a system in which a bug can literally result in life or death (ie Software for planes or medical equipment).

I am lucky enough to have experienced many of those contexts – and I’ve assumed developers are aware of this; people will change their approaches.

But as I mentor developers, and work with large development teams, I recognise the line is not always clear for everyone. The need to discuss the context explicitly is very important.

Is this a Spike / Proof of Concept that will be thrown away?

Is this an MVP to gain insights and validated learnings?

Are you building a business critical service for a Fortune 500 company which requires 99.95% uptime?

Craftmanship depends on the context.

Have the team agree on the approach; the level of quality, reliability, maintainability, DR, etc.

It is fundamental for the team to be on the same page, but it is just as important to ensure your stakeholders align to this.

 

 

Pragmatism and Business Acumen

The other week, I was having lunch with our CTO at PageUp Tal Rotbart, and we were discussing various issues in the industry, where he posed a question to me that got me thinking  – “Isn’t pragmatism just business acumen?”

I’ve been pondering the question for some time now… Let me first start with defining the two.

Pragmatic: dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.

Business acumen: is keenness and quickness in understanding and dealing with a business situation in a manner that is likely to lead to a good outcome.

Given those terms, both seem to speak to similar traits in terms of software development, but the problem is, both can be very relative. Also, business acumen seems to be higher level concept, which can encapsulate pragmatism.

Pragmatism without business acumen can be just as deadly to a company as not having pragmatic approaches to start with.

Which drove me to start thinking about seniority levels within a development team.

Continue reading Pragmatism and Business Acumen

Continuous Delivery

Recently, I’m hearing a lot about continuous delivery, and even continuous deployment. Both are fantastic, and I’ve seen many places reap the benefits of such models.

Continuous delivery is when the practices used by the team enable the software to be reliably released at anytime. Every change has the confidence to go straight out to production.

Continuous Deployment is the next step, where the software is not only ready to be released, but is released out to users. Every commit out to production.

I see software which is released less often, because it is risky, and often, a scary proposition. The objective of both practices is to make deployment a “non-issue”.

If it hurts, do it more often

Left out of the conversations is the value it provides. Not from a technical perspective, but from the business. After all, that is the reason we do anything. For provide value / benefit to the business.

Our objective is to minimise our time to market, which is a another topic in its own right due to the many factors that impact that metric.

We need to ensure our software development keeps its agility, and enables quickly responding to feedback.

The main reason why these models are so beneficial is because packaging, regression testing, deploying, waiting and so on, are non-value adding activities. These activities can be mundane, tedious, and should be automated if possible.

Business should not be waiting for Technology, Technology should be waiting for the Business.

As we all strive for that goal, these two models take great strides in getting closer to the mark.

If we find resistance for these two approaches, you will most likely be dealing with software which has lost its agility, or struggling for quality, and we all know what happens in that case…

How important is UX?

User Experience has been gaining momentum and importance within companies, but have leaders really connected with what it means?

It is hard to argue, that user experience is paramount, in engaging and retaining users / customers. I’m sure most would agree that it is simply common sense.

But we are still in an age where good UX can be a market differentiator. How many companies are driving UX as a high priority?

Even more importantly, which companies have its leaders (C – Level, ie – CEO) pushing for, and driving UX?

Companies need to stop focusing on revenue, and thinking about UX. Revenue is a by-product of UX.

When we think about the metrics that top level management focus on, I assure you revenue would be very high on the list, if not top. Rightly so, but perhaps a shift in thinking, to focus on building raving fans (aka UX), will enable the revenue growth simply as a by-product, and perhaps a few other metrics such as staff satisfaction and engagement.

Food for thought…

 

The pragmatic craftsman

I’ve been working in software development for a solid 15 years now, and I’ve seen all sorts of projects, and developers.

While software craftsmanship is talked about a lot, and quite often seen in job ads; one thing often left out is pragmatism. In fact, I’ve seen software craftsmanship taken so far, that it has killed projects, and products.

This is not a post to say craftsmanship is bad, I am the first to admit writing good, clean code is very important for the long term survival of a product. There is value in good, clean code without a doubt. Unfortunately, I see it very often, developers over think a solution, or try to flex their “technical muscles”. What results is an over-engineered, or overly complicated solution.

Pragmatic – Dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations

Stepping back a bit – Our job is to solve problems, in a cost effective manner.

Not to use the latest technology, or patterns to build your CV. It isn’t to use CQRS, Event Sourcing or Docker because it is cool. And not to mention over designing, products for every edge-case up front.

No one can design the perfect solution up front. An idea I always try to drive through teams I work with, that has served me well – deliver quickly, and leave time to iterate.

A question I always ask during design reviews is – “Do you need it?”. At times it could be a pattern I am questioning, a framework, or technology. I’ve even done it to automated tests.

If the team cannot outline value a choice is going to provide, it shines light on it very quickly. It isn’t to push back, or cut anyone down – sometimes I use the question to ensure the team understands why a choice was made. As we all know – there are no silver bullets.

And a reminder – Tests aren’t the only thing that will sustain the software over the years, it is simplicity. Many developers will work on the code base, and our job is to make it easy to understand, and safe to modify.

The “pragmatic craftsman” as I call it, is one that not only builds well crafted software, but focuses and delivers business value iteratively. They cultivate raving fans, should be egoless, humble and most of all, focus on the outcome.

I enjoy working with talent developers, but I love working with pragmatic craftsman.

Hello again world

As my first post on this new blog, I wanted to write a big thanks to two people who have given me the nudge to start this blogging again.

The first one is Tal Rotbart. I’ve worked with Tal for close to 18 months now at PageUp, and I’ve got the say, I have learnt a great deal from him in such short space of time. He is a very strategic thinker, and quite a different mould of “techie”. One of the most talented guys I have worked with.

He encouraged me to focus on building a public profile, and share my thoughts. So… here I am, back to blogging.

We are currently on a very interesting journey, realigning a product company, as well as the classic journey from Monolith to Microservices. I have grown a lot, and learnt a great deal of things in the past 18 months, so this is the start of sharing some of those learnings.

The second one is John Sonmez. I’m sure John has influenced quite a number of developers, but I’ve been following John’s work for a number of months now and he has an interesting way of connecting. His free course on blogging is what got me going, and to be honest, it is a little more fun with the structured approach he has provided.

I’ve been in touch with John through this free course and it is nice to have the personal touch – not just an automated email system.

So cheers to both of you!