My company, Hallam, attended a whole company outing to the Google HQ in Dublin last year, and part of that involved a talk about the “Agency of the Future.” The talk focused on how changes in the labor market and the evolution of technology will require the development community (and other related digital communities) need to evolve from optimizers to consultants.
In this article, I will branch out from the regular technical blogs published on this excellent website and start to discuss soft skills and behaviors for developers that will help the community rise from being optimizers to consultants.
It’ll be no surprise for the guys in my team to read this and hear me talking about The Clean Coder, A Code of Conduct for Professional Programmers, by Robert C Martin (aka Uncle Bob).
One of our developers introduced me to the book (thanks Pog!) and it’s been a genuinely life-changing experience. This article isn’t a review so I won’t go into detail, but the key theme underlying the book is about how developers are (were?) not treated like the professional services industries such as lawyers & accountants.
Uncle Bob relates back to a story where he was expected to work on a Saturday to deliver a project, but was denied access to the legal team for whom he had crucial questions on that Saturday “Because they are professionals.” The book explains some behaviors that you can take on which help you behave like a professional would, with the aim of being treated like one.
One of the particular points that resonated with me was a moment when an old system that Uncle Bob had been working on had been retired and he wanted to bring it back. The CEO of the company said to him “OK Bob, work up a plan. Show me how I can make money. If you do, and I believe it, I’ll start up [the project] again.”
Behave Like a Professional, be Treated Like a Professional
That got me thinking that by and large we, as developers, often think like developers and focus on new tech, new libraries, new platforms to test our code, and the list goes on.
It’s easy to fixate on the technical side of our work, but the reality is that we are required to think commercially and on behalf of the businesses and clients that we’re working on. For me, it’s a skill sorely missing from many developers and a skill which can elevate you from a good developer to a great one.
But, “that’s a Project Manager / Product Owner / Analysts / The Client’s job!” I hear you exclaim and you’d be partially right to think so. It is their job, but there are decisions that these roles don’t get involved in which can have a profound financial effect on a business that we as developers must take responsibility for.
I started and run my own agency, so I often take this way of thinking for granted. Recently I’ve come to realize that we can all benefit by thinking this way and if we benefit as developers, we can pass that benefit on to the rest of our team and our clients. Anyone that works in an agile team should already know that cross-functional teams are a necessity, and cross-functional doesn’t just focus on development work.
Re-Inventing the Wheel
I want to run through a recent project I’ve been working on to highlight this exact problem.
This particular client sells music CDs across Europe. They had a website built around eight years ago which has been continually iterated since launch. The client approached us because they wanted to improve the conversion rate on their website so we started to dig into what they already had.
Problem number 1: the developer had built a bespoke eCommerce platform for the client.
Effect: nobody else other than the original developer could effectively support this eCommerce platform. This tied the client to this developer. Some may say this is a deliberate strategy to protect the contract with the client.
Lesson 1: Don’t reinvent the wheel. Hours/days/years have been but into existing proprietary (or preferably) open source eCommerce platforms, content management systems and libraries, so take advantage of all that hard work.
To make my stance on this clear, I’m not against bespoke websites when necessary, there is absolutely a need. Eight years ago there were already eCommerce platforms that could have been used to build the site. Nowadays there are plenty of eCommerce platforms to use including our beloved WooCommerce, so there is rarely a case where we need to build a bespoke one.
Technical Architecture
Due to the nature of how the music industry works there are some quite complex rules about where music stock comes from. Some of this stock is held by the retailer, others by the distributors, and different distributors have different rules for minimum order requirements. This all gets quite complex to manage, so naturally, the client had requested that this complex workflow was built into the way that the site they had build works.
The developer then built this bespoke functionality into the website.
Problem number 2: the developer built complex functionality around the business logic into the eCommerce website itself.
Effect: Websites should be treated as expendable and as technology moves on, it can sometimes be more cost effective to throw out what you already have and start fresh.
Lesson 2: Don’t mix complex business logic which works against the website’s primary purpose. Keep the website’s purpose clear and specific, and build separate systems which can be integrated with for managing business logic. This client needed an order management and purchasing system, not an overly complex eCommerce website.
It was clear that the existing platform was not easily customizable (see problem number 1), would require a major learning curve for our team to work on which would mean it’s not cost effective for us to work with it.
Naturally, we considered WooCommerce as the best platform. The client has a complex product catalog, but not so complex that we’d be thrashing WooCommerce into an inch of its life.
All Websites Become End of Life
We then started to look into the requirements of the site. Most of the requirements are fairly standard eCommerce functionality, but there were some very specific requirements based around the points I made above about distributors and minimum orders.
There are no existing plugins in WooCommerce that support this functionality, so we then start to talk about how to solve this problem. The client has a decent budget but it’s not endless, and it’s clear that there wasn’t enough budget to replicate the functionality they had, neither was it necessarily a good idea.
Problem number 3: the client is in a position where it’s not cost-effective to replace their existing website
Effect: The client is stuck with an old EOL platform
Lesson 3: PHP developers code with OOP in mind, where objects are discrete and decoupled. Apply this principle to overall technical architecture so that individual elements can be replaced, rather than the whole application.
Conclusion
As our industry shifts from a small number of trailblazing developers, to heavily funded government schemes focused on skilling a large number of developers, and the rise of cheap development houses, and then on to the not too distant future where AI automates some of the simpler aspects of our job, developers need to evolve with it.
Are you afraid of this? My thought is that we shouldn’t be afraid of this; we should evolve to ensure we’re offering the best value we can to our team and our clients, and thinking with a little more commercial awareness will go a long way towards that.
No Comments