When you have a hammer, everything looks like a nail | Hacker News Reader

When you have a hammer, everything looks like a nail

sittingonhands.blogspot.com

30 pointsyosheeck28 comments

> 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?

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?

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.

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.

Quote from OA

"Instead of solving the situation, they add more and more advanced tools on top of existing software development chain..."

I'm wondering if those layers of more advanced tools could be re-written piecemeal so that they pointed to a more rational underlying system? Sort of jacking the house up to work on the foundations?

PS: Saltaire (I'm guessing) is a lovely town and the 1853 Gallery at Salts Mill is a must if you are in the neighbourhood.

Yes I thought of Pace too. I second a visit to Salts Mill. Great collection of Hockney's.

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.

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.

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

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.

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

I think it has more to do with the first point. That's the culture, and culture tends to perpetuate itself, especially if it's a big corp where people stick around way longer than in startups, and it's a much bigger burden to switch tools.

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

I used to work at Cisco, and I have the exact same opinions.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

Any blacksmith will have different opinion.

Reply on news.ycombinator.com