Favouring Tools Is Bad Engineering

Today I want to talk about bad engineers, and one aspect of them in particular - solution favouritism. But first, let me remind you again how engineering is supposed to work.

You get a problem - this could be anything - you might need a new database, a new frontend framework, a new package manager, or even more abstract, you might need a new way to show data to a user when it’s convenient for them. Heck, it could even be not software, you need water to come out of a tap, you need a new shower unit, you need a bridge to cross a river, you need to provide electricity to a remote region.

Then, you go deep on the problem. You look at the sub-problems, the unique constraints to this field, your company, your people and team, your future plans, your past plans, and much much more. These all matter.

From there, you try some solutions. You try each solution you can think of in turn, with small proof of concepts (POC) or experiments, and eventually you see what works best. You might rule some out because they’re not working well with your unique constraints. You might test others even further. This is where some knowledge of solutions can come in handy, but more on that later.

From there, you settle ties. If one solution seems pretty much the same as the other, you keep going. Find other unique constraints until a clear winner emerges. From there, you can go on to implement the solutions. If you find issues, then your POC wasn’t good enough, and you need to go back a step. It happens. It’s fine.

And that’s it, thats a (simplified) way to do solve problems as a good engineer.

Now, let’s talk about what bad engineering is.

Bad engineering is going into a problem solving phase with a bias towards your favourite potential solution. This is absolutely absurd yet it happens all the time, especially in software engineering and especially online. This is becoming too common online, and it’s super super sad to see. Let me list some phrases which I think are signs of bad engineering:

• “We only use Swift now”

• “I prefer Cocoapods instead of Carthage”

• “You don’t use Typescript????”

• “VS Code is the best text editor!”

• “Oh, its Uber for <x>”

• “You should use the architectural pattern <X> for your next project”

• “You can only scale if you have kafka in your stack”

• “How can we use AI in this?”

• “It’s X but using the blockchain”

• “Lol you aren’t using ES2018?”

• Ha! You still use PHP?!”

• “I want to use X because I want to go to XCon this year and do a talk”

• “I cant wait to use X in a project!”

• “I want to use X, I saw a cool talk about it!”

• “I’ve used architecture X, so we’ll use it in this project”

I want to go even further than this. I want to say its bad engineering to even like a technology or tool. If you like it, you’ll have bias towards it when it comes to problem solving, and you’ll be a worse problem solver (aka engineer) for it. Sure, I find Swifts syntax pleasant, or readable, or maintainable. But at the end of the day, I’ll use it when it’s the best possible way to solve a problem. In the context of iOS apps, Swift can fairly lose to other possible solutions given the right constraints, from anything to Objective-C, to React Native, to a mobile website, to a better Google listing on Maps through to a simple flyer drop in a local area. ‘

We are engineers. We solve problems. We don’t walk around with a box of solutions and contorting them into the problems we come across. We look at the unique constraints of the problem at hand and go from there.

”But Sam, I’m good at X and that’s why I like it, so I can do things faster and the business likes me for it”. That’s fine. It’s fine to be good at a particular tool or technology. BUT, it’s only a good solution if the constraints are correct. Some (common but not constant) constraints that might lean towards these situations are:

• You already have a codebase of X, so you add more X (eg Ruby to a Ruby codebase)

• Delivery date is near and/or cost must be kept low - so you emphasises your/your team current skill set in a search for a solution. As a good engineer, you warn management of the long term risks of not doing it the right way. See: startups.

• The project is short term, such as for a tech demo, temporary use or similar.

So, in summary, there are a few key points I’d like to drive home and make clear.

1. Start with the problem. Work hard on dropping your biases, and evaluate fairly using good scientific and engineering principles

2. Watch out for blogs and online content selling solutions as a solution to your unique problem. It may be a solution, but I can guarantee it isn’t everyones solution.

3. It’s fine to dive deep and master a technology, but the best engineers or developers don’t have a tool name in their title. Senior Java Developer sounds as ridiculous as Senior PVC Pipe Plumber. The best start with the problem and find the best solution for it.

4. Some blogs and online content focusing on a certain tool are usually there to make you more proficient in using them, but watch out for assertions you now know are intellectually dishonest and bad engineering.

Good luck with all this! The future will be amazing if we keep looking at problems and coming up with the best solutions. If we use what we have now going forward, we’ll stay pretty stuck. And we don’t want that.

from Hacker News https://ift.tt/3eTLJSO