Category Archives: Rants

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!