What separates software consultancy from engineering? Breadth of vision
July 13, 2015 in Engineering philosophyYou might think that making great software products automatically makes you eligible to be a software consultant. Well, as I discovered, there’s a significant difference in mindset between being a good software developer and a good consultant.
To build great software products, you only need to know just one way of doing it. Thanks to the malleability of software, one good approach will work for many, many projects. Furthermore, turning the approach into a dogma and religiously adhering to it can yield even better productivity and quality in your products.
You might even be good at teaching that dogma to newcomers. (You would need teaching and communications skills, which you might or might not have.)
But to be a consultant, you have be able to recognise any valid way of building a product. It’s a step higher in the ladder of abstraction, like a move from algebra to calculus or from propositional logic to predicate logic.
See, there is more ways to build software than any other kind of product - and even more are cropping up every day, which might not have anything in common with what you are familiar with. Still, you need make rational assessments of the architecture in question, and apply a level of knowledge more general than how you yourself would make an awesome product. Unless you are explicitly asked to preach your specific dogma, you’d best keep it to yourself.
How to be a better consultant
Do not be offended when “their way” clashes with “your way”. Especially if “your way” seems inferior - which is a great opportunity to learn and get inspiration.
Separate “your way is not like my way” issues from issues that are truly harmful. For example: not every web application must have a RESTful api layer, or a UI-independent business model, or follow SOLID practices. But every application must be protected from malicious user input. And not blow the stack. And produce responses in a reasonable time.
This separation is highly opinionated. And, I think, the ability to identify the fundamental errors, to separate wheat from the chaff is crucial for a good consultant. In fact, I think it’s the one thing the consultant is hired for - having a mental model of what good software products looks like, without getting too much into details. You can improve that mental model by reviewing and analyzing software products - varied in authors, technology stacks, and goals. Fortunately, in the age of GitHub it’s easier than ever.
Most importantly, be civil and keep calm. Think and, ideally, discuss your concerns internally before expressing them in a non-confrontational manner.
Liked the post? Treat me to a coffee