Comment by aero142 | Hacker News Reader

Comment by aero142 | Hacker News Reader

Parent Full thread

You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I've personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.

> Ultimately, developer retention and hiring suffer because no one wants to work on these products.

This was/is indeed the case for that organization.

> The institutional knowledge leaves through attrition

They have addressed this problem by simply silo-ing knowledge with a few key people who were very well compensated (think 10's of millions in stocks). These guys (the senior developers in my example) would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.

> Eventually the quality of the product declines until customers leave.

I think more than the product becoming worse, it will simply be out-competed by better products. This will happen slowly though. By the time it does everybody who's anybody will have cashed in and moved on.

> would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.

I'm curious as to how they would do this. I ask because I've seen both sides: as someone new to the company trying to understand the lay of the land and being frustrated at the lack of documentation, and on the other hand being asked for more documentation about things but not having the time to do it because of being pulled into doing other things and simply not having the time.

It also seems like most junior (for lack of a better word) developers often don't read documentation anyways, so it seems like a waste of time to go above and beyond to write docs.

HOWEVER. It is completely and totally inexcusable to build products without code review, regardless of how senior you might be. If its a spike or POC, fine. But if you're going to productionize it... you better have someone else review your code. I did see this happen and its a horrible problem: these "Senior" devs build totally unstable systems and offload them to another team to maintain; the poor team then spends most of its time putting out fires...

> most junior (for lack of a better word) developers often don't read documentation anyways

Though there are many other factors that contribute to excess reliance on tribal knowledge, I consider this a huge contributor to "bits and pieces" knowledge transfer. There are many people who ask others for help immediately upon encountering a problem, and they (as a group) reliably ask the same basic questions over and over. Many ask the same questions more than once, for years on end!

My honest answer to these questions is "fuck off, read the docs and don't just dump error strings into chat and rely on other people to do your job for you. Come back if you're still stuck after reading the docs with an explanation of what you tried." However, these questions are often asked in public fora, and I feel that I'll gain a reputation of being surly and not a team player if I respond earnestly: I'll give a "bits and pieces" response that probably answers the question without explaining my thought process or giving context with the aim of making the question asker go away as quickly as possible. I wish I knew how to effectively guide people into the habit of trying to find their own answers first without coming off like an asshole, but figuring that out is harder than just providing the answer.

There are, of course, plenty of things that /are/ poorly-documented. Giving bits and pieces answers for those /is/ harmful. But the same question pattern happens with public tools that are extensively documented (the Python standard library or Kubernetes, for example), and it's draining to babysit people that never learned how to, well, learn.

I have faced the same dilemma and don’t have a good solution either. An interesting twist is that people that ask basic questions that can be looked up then “DM” me on slack. My approach has been to ignore such questions; often I legitimately lose track of them anyways, but I don’t like the approach simply because it seems anti social. Then again I am only a human; it’s hard to provide one on one assistance to everyone that asks.

> I'm curious as to how they would do this.

No documentation, testing or code reviews, selective knowledge sharing (only to some people at some times, the others might get yelled at), code that is not easy to understand on its own (not impossible of course, just hard enough that you won't bother understanding unless you really had to).

Big decisions were not really discussed with anybody except a select few. The regular developer would simply have things communicated to them e.g. from today we're using Git instead of Subversion, from next week we're doing weekly instead of monthly releases etc.

Of course, if you were persistent and really interested you would get to know more about the platform. It's just that things were made hard enough that most people wouldn't really want to do it.

Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues.

I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.

My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there.

Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite).

I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?).

Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do.

In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog.

Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.

I'll agree with you on that.

Take PHP as an example. I'd say from a technical perspective not many people would go with it from a technical standpoint but we can't ignore that massive companies like FB for example were build on that (no matter if they grew out of it at a later date).

> I've never seen a product fail because of poor engineering practices.

I've seen plenty of things fail due to extremely high costs to develop basic features with few enough bugs to satisfy customers. That is mostly the result of bad engineering practices, like choosing C++ instead of PHP for your web servers, or just plainly having bad engineers who don't know how to build a big project.

What kills those products is not the bad code itself, it's the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it's less of an issue if you have a very profitable product and/or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it's much bigger of an issue.

Reply on news.ycombinator.com