DEV Community

Favouring Tools is Bad Engineering

Sam Jarman 👨🏼‍💻 on November 23, 2018

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 engin...
Collapse
 
ky1e_s profile image
Kyle Stephens

Hi Sam, great post. Completely agree.

One additional problem I've also observed about tools is a desire to use the latest technologies just for the sake of it.

I'd personally much rather a well-architected, well-written solution in a slightly older stack than a hap-hazardly thrown together project in the latest tech.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Yup! Trying something because you read about it or saw it at a conference is fine on your own project, but suggesting its the best because the newest tends to be more wrong than not

Collapse
 
larrojl profile image
José Luis Larroque

Hey, good topic, I agree with almost everything what you said, but I'm not sure about this line:

"Senior Java Developer sounds as ridiculous..."

Every profession has specialists in a certain area, why not programming?

And, let's talk honestly, if you really agree with what you said, you shouldn't refer yourself as Software Engineer in iOS/Rails... :)

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Lol! Fair fair, I tend to write that so people know why [on twitter] I follow them. At the moment i'm working on an iOS app adding more swift and objective C to it, so I write that. However, if a problem is best solved with a poster in our retail stores... I'll say that too! Open mind always.

Collapse
 
coderlog profile image
Xavier

Hi Sam, I agree with your article almost entirely. But I also think that quite often the constraint is precisely in the engineer knowledge. In the time that takes learning another technology. Usually the things we don't know surpass the things we know.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻 • Edited

Thanks, and Yup! I think if you're constrained by time, its good to play to your strengths. But if not, or you know what you know isn't enough, it's time to study up! This is stressful, but never a waste of time :)

Collapse
 
carlfish profile image
Charles Miller • Edited

Your description of “engineering done right”, where engineers understand the whole of the problem in advance and evaluate multiple competing proofs-of-concept before starting the “real“ work, is the myth that brought us waterfall.

As an aside, in the early 2000s I worked on such a project: an attempt to replace a financial institution's ageing mainframe system with something that would allow the company to branch out into new products. Use cases were defined, specifications were specified, technologies were trialled and chosen for all the right reasons, and eventually engineers started engineering.

Two years and a few million dollars in, the project owners made the inevitable discovery that they were building the wrong thing with the wrong technology. The only part of the system that was delivering value? The quick-and-dirty interim hack for scraping the old mainframe’s green-screen UI and turning it into web forms.

So it turns out, sometimes the solution is writing a front-end framework in COBOL.

A major theme of evolution in software engineering over the last twenty years has been accepting that we don't understand the problem in advance (and in many circumstances can't understand the problem in advance); reimagining development as a process of iterating towards a better understanding of what we're trying to build, while we're building it.

The only thing more certain than us not really understanding the problem we're solving today, is that whatever problem we do solve today, we'll be solving a completely different one tomorrow. In this world, the idea of picking the “best tool for the job“ falls apart because we don't really know what the job is.

PHP looked like the right tool for Facebook up until it wasn't, and they had to write an entirely new language and runtime to replace it. Rails looked like the right tool for Twitter until it wasn't, and they had to sink years of development and lost feature momentum into replacing it.

I'd go as far as saying (in an idea parallel to Tom DeMarco's 2009 essay, Software Engineering: An Idea Whose Time Has Come and Gone?) that the more we can with any certainty decide in advance what the best tool for the job is for any given project, the less important that project is, and therefore the more likely the right choice for that project is whatever tool we know already.

So for important projects, the ones where we have to make decisions about how to solve problems we don't even know we have yet, it is our job as engineers to have an informed opinion about which technology and tools are just better for their general problem domain. The tools that will build upon the successes, and help us avoid the failures of the teams that came before us.

Certainly there are good and bad reasons to prefer one tool or another, and falling in love with some tool so much that you can not see its flaws is a too-common disease, but saying that having any preference at all is “bad engineering“ is an abdication of our responsibility to improve our craft.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Hey Charles, thansk for your awesome reply, some good points there.

You're right- what we're building is increasingly unknown in with agile software dev, and with startups and technology innovations in general. And your bank example is a classic story we've all heard too many times. However, I'd encourage readers not to just apply the above methodology not to whole projects, but any subtask, no matter how small. We do it all the time, Integer or Float here, Enum or String?, Right up to class, to package, to framework, to OS etc. I'd even argue (over a beer, my fingers only have so many key presses in them haha) that Agile looks like mini waterfall sometimes, and that's not necessarily a bad thing, agile is adaptable to the problem and the people.

I definitely think that my assertion of any preference is perhaps too strong of language, so I'll add some subtlety, I think it's strongly advised to proceed with caution when considering your preferences. Are they engineering reasons or other reasons. Engineering reasons are the best way of course :)

Thanks again for your time!

Collapse
 
vasilvestre profile image
Valentin Silvestre

I love this point of view because I'm doing old javascript with var everywhere and I'm an adept of PHP so I'm forced to agree!

Using the right tool also depend on your environment, colleagues, skill and more... People are too judgy and elitist.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Yup!

Collapse
 
lepinekong profile image
lepinekong

I agree (who wouldn't) but in real life, especially in big corps, you cannot switch people like apples or oranges, so you do with the competencies you have at hand. Personnaly I'm not fond of Java but I have to manage java projects since that's all I have at disposal, I have to fight to even get other profiles like javascript or webdesigner as these guys pretend to be "fullstack" but in truth they cannot do CSS hackernoon.com/the-backendificatio... ;)

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Sure, I think playing to a teams strengths is a valid factor in choosing a technology :)

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

I'd add some nuance here - If you have, for example, a jquery website, and you're making a tweak... then no need to rewrite it.

If you're looking to pick up an old project and add 3 years of dev to it with a large team... then yeah, moving to a framework (I wont say which, depends on the problem) might be a good idea.

Elixir is not a JS framework last time I checked haha. Although I'm sure someones written a JS transpiler, for some reason.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Another good approach! And yeah, I agree with this 'I understand that most of the problems can't be solve with my tools set. That's okay.'

Collapse
 
helenanders26 profile image
Helen Anderson

Great post! Thanks for sharing this Sam.

It seems so simple when you read it like this, but so many struggle to break it down like this and not jump right in with a solution in mind.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Thanks Helen, I appreciate that :)

Yup... we're all guilty of it! But we gotta be better than that eh!

Collapse
 
vitalcog profile image
Chad Windham

“How can we use AI in this?”

+1

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

LOL yup

or Blockchain :P

Or IOT

Collapse
 
david_j_eddy profile image
David J Eddy

Excellent article Sam! I look forward to your next one.

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

Thanks David!

Collapse
 
galdin profile image
Galdin Raphael

More often than not, the bias is towards familiarity than favorites IMO

Collapse
 
samjarman profile image
Sam Jarman 👨🏼‍💻

That's a good and subtle distinction, and an interesting one to unpack. I talked to it a little in the post, but ultimately, you need to be honest with yourself if the speed gained now using what you know is better than taking the time to learn something new that'll better solve the problem now and into the future :)