
When you have a hammer, everything looks like a nail - yosheeck
http://sittingonhands.blogspot.com/2013/06/if-you-have-hammer-everything-looks.html
======
Toenex
> A big (2B+ $) company. The division in the middle of UK. They make Set Top
> Boxes - they are somehow good at that.

So, despite what the author thinks about their methods and their technology
choices and despite anecdotal intermediate performance indicators ("Solving
bug takes ages") whatever they are doing is working.

How many start-ups do we read about on HN that are using the latest and
greatest language/framework/stack/methodology and yet don't yet have a
business?

~~~
chuable
Interesting way to look at it. You could look at it another way and say what
whatever they were doing before worked and got them this far. However, will
what they are doing work for their continued future?

~~~
TheOtherHobbes
It might. It might not.

What would the technical and cultural cost of moving to a different toolchain
be?

The author seems to think that _obviously_ moving to modern tools would be
better.

Would it? Or would it just add to the chaos? Would build times really improve,
would debugging become easier and more streamlined, would issue tracking
improve?

My guess is that changing the entire culture to the point where there were
real, measurable benefits would take from a few months to a year, with a lot
of unproductive downtime.

The current toolchain is not optimal, but it still sort of works. And in a
limited environment like set-top, it will probably continue to work.

Bottom line: don't innovate tools for the sake of it. Innovate if it's going
to give you more customers and more profit. But not otherwise.

~~~
cheatsheet
Real innovation doesn't lead with absolute certainty, it does not know whether
it will lead to a reward. I really don't understand the mentality here where
everyone thinks they know what they are doing before they do it. I can
understand the need to have confidence and the desire to measure out a metric
of predictive possibilities, but they are only predictions. For some things,
you really don't know what will happen until it happens - especially when it
involves chaotic systems such as people and their wants/needs/desires.

------
Spearchucker
There's this tendency I've started seeing more and more of in recent years.
People pick an idea (be that a method, a technology or a philosophy) and make
that their world. So you have people loudly proclaiming "We're agile", or
"We're FOSS".

This isn't necessarily bad. It does get bad when it's exclusive of anything
else. When someone tells me they only ever do something one way, what they're
_really_ saying is "We're incapable of introspection. We like our self-imposed
status quo, and have no interest in improving ourselves."

Of course the other extreme is just as bad - change for the sake of change is
just as destructive.

~~~
lostcolony
Slight tangent, but, the funny thing about "We're agile" is that it means so
many different things to different people.

I've heard people describe themselves that way when they meant "We have no
process", "We have a very specific process that we adhere to religiously, that
has been billed as agile", and "We have a process that we are constantly
trying to improve, through retrospectives and the like to figure out what
works and what does not". Only with that latter one has the work seemed to get
done on time.

~~~
Spearchucker
Yeah, there needs to be some maturity. It's rare, but it exists. I once worked
for a consulting company where they chose their methodology based on the
cultural environment of their client. It prompted me to put this post together
-
[https://www.wittenburg.co.uk/Entry.aspx?id=d84dff2a-c5cd-463...](https://www.wittenburg.co.uk/Entry.aspx?id=d84dff2a-c5cd-4638-9141-76568e4cc58b)

------
skrebbel
All hardware companies I've seen on the inside are like this. Philips, FEI,
Cisco, ASML, Océ. Somehow, when software isn't the only part that matters,
people stick their heads in the sand and pretend like the 1980's never ended.
I've given up trying to figure out why or change it.

It's the only reason I only do web stuff now. I like both domains, but the
hardware / embedded software industries are just retarded.

~~~
nappy-doo
Longtime embedded engineer here:

There is a reason they are "retarded" (BTW, please don't use that word). It
comes down to the following:

1) Embedded engineers are generally EE that have taken a course or two in
software. Generally they are the "best software guys" from a group of middling
to poor software guys. As such, they reach for tools they are familiar with.

2) The product from embedded engineering is much different from web
development. It might ship on a ROM, for a part with < 64kRAM. In
circumstances such as this, knowing your toolchain won't add any complexities
you don't understand is very important, and it doesn't get much simpler than
C. (Also, most good embedded engineers use a restricted set of C that doesn't
include things like printf and malloc.)

~~~
skrebbel
> BTW, please don't use that word

Good point. I won't anymore.

Your experience matches with mine (especially point 1). It's a sad state of
affairs, really.

Wrt point two, true, but these days there's a vanishingly small number of
problems that can only be solved cost-efficiently on microcontrollers and C.

My favourite example is ASML, world market leader in chip machines, which sell
at millions of dollars a piece and could be specced to have any computing
power needed, effectively, and has a software stack of 30 million lines of C.

Running on microcontrollers and Sun Solaris computers.

------
hrktb
If a team with extensive experience in CVS is already dragging it's feets to
move to SVN, trying to get it to git is a fool's errand.

And SVN isn't the plague either, if they could be happy with, it should be
good enough for a number of years. At least the migration path from CVS seems
a lot more realistic.

Moving legacy systems is always a pain, and more often than not it's a matter
of having enough people fluent in the target technology. I guess the point of
the rant here is to urge people to get new hammers when their current one is
getting old.

~~~
coldcode
10 years ago I managed to convince my employer at a time to move to Subversion
from some proprietary system. Labelling a version of their customer facing
application took all day as it copied every single file. We moved the code
into Subversion as a test and showed we could label it in 1 second. Sometimes
you have to show people to get them to understand.

~~~
hrktb
I think convincing people is usually the easy part. More often than not
they'll have shopped around and choose the solution themself. Or they hit a
wall with the previous solution and need a new one no matter what.

I remember the tedious part being actually moving all the projects, all the
teams over. Change the procedures. Change the tools, be it on the dev
machines, CI, managers etc.

Then you remake all the weird scripts that were used to take stats, the commit
hooks, or the stuff people didn't even remember existed but is still critical
0.01% of the time.

Usually it won't be done in one scoop, more like building the basic viable
architecture and moving one project after the other, keep both stuff working
in parallel with some people who'll trail behind and keep some translation
layer between the legacy and the new system until everyone around has moved
and they feel the peer pressure.

I've seen a lot of these transitions in mid size (70~200 people) corps, it
would easily take 2 to 6 months to complete, even with goodwill on most
fronts. Not the best memories.

------
emsy
I've been in a similar situation, though not nearly as dramatic. I've noticed
the same effect: the talented people leave the company out of frustration. We
talk about 3 people quitting in 6 months. In my opinion, it's a situation that
happens when a B or C player manages to hire a B or even an A player.

And here is how it happened: In my case, I was transfered to a company that
worked in cooperation with my initial company, so I didn't really have a
choice. One colleague was very talented, but coming from a foreign country he
couldn't really judge the company. The second colleague started at the company
after graduation but grew out of it by learning and doing side projects after
work.

I can understand the authors frustration, but I'd like to know how he got the
job. If you knew the culture beforehand and joined with the naïvety that it
would change for him, he should really be more modest.

~~~
velox_io
My first programming job was in a company like this. I was there 6 months and
that made me question if I wanted to do development as a career or was cut out
to be a developer. I moved into operations/ systems in another company.

I gradually fell back into development in my new job, did a computer science
degree part time. Now I really enjoy programming/ creating.

There were warning signs before I ever accepted that job (which ignored
because it was well paid). Now I know that money isn't everything and there's
work out there where you simply couldn't pay me enough.

------
caminante
I tried, but couldn't make any sense of this rant.

~~~
Stratoscope
The author certainly hammered away at it, but I don't think he hit the nail on
the head.

------
probablybroken
The situation described here looks to me like a team drowning in technical,
product oriented difficulties that prevent anyone from having the available
bandwidth to introduce new methodologies because of the chaos that doing this
on the run would ( or would be perceived to ) introduce. In my experience,
engineers need the headspace to learn new tools in a non impacting situation,
which usually requires the introduction of low risk side projects to learn the
new tools and techniques. In a way, this is actually a staffing / time related
issue.

------
Puts
I used to cite this saying all the time. Now I'm more keen to think that this
saying can be twisted to support just about any argument.

------
huuu
I think this is mostly a management issue. People dont like changes. So as
long some changes are not forced nothing is going to happen.

And if a company only uses rakes to dig holes imho you can either try to
convince management that using a spade is better or stop complaining or just
leave.

------
vacri
aytekin, your last three comments in your history are marked dead. I don't
know why, they seem innocuous, but you may want to contact the mods.

------
chrisbennet
The actual phrase is _" When all you have is a hammer, everything looks like a
nail."_

------
jkot
Any blacksmith will have different opinion.

