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 eng... [Read Full]
markdown guide
 

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.

 

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

 

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... :)

 

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.

 

Thank you, Sam.

I totally agree on your list of "phrases which I think are signs of bad engineering". It's painful to hear those phrases when we talk with engineers.

Also I'm sure the spectrum is quite wide: from high-level engineering with the best tools available to a narrow subset of problems with the tools you know the best.

For me these days programming became a craft and I only pick projects where I can use with my favorite tools. I understand that most of the problems can't be solve with my tools set. That's okay.

 

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.'

 
 

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.

 

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 :)

 

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.

 

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!

 

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.

 
 

I mostly agree, but some tools deserve to be buried 3 feet deep. For instance, if thatโ€™s is about new feature in Rails behemoth, or about new site section in the site built on top of jQ, it always makes sense to shift to Elixir and any of modern JS frameworks.
Iโ€™ll pay back literally tomorrow.

 

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.

 

{Ruby/Rails, jQ} โ†’ {Elixir/Phoenix, Modern Framework}.

 

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... ;)

 

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

 

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.

 

Thanks Helen, I appreciate that :)

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

 
 

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

 

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 :)

 
code of conduct - report abuse