How Software Companies Die (1995) [pdf] | Hacker News Reader

How Software Companies Die (1995) [pdf]

homepages.uc.edu

98 pointsSomething123448 comments

Posting anon for obvious reasons.

I recently worked at a "high growth" software company (database vendor), A-round funded, that faced this. First decision was to demote all the engineers from hiring titles down to mid/entry-level.

The worse things got, the more product managers they hired and promoted. Then things got worse and they promoted more sales persons. A bunch of golfers managing a highly complex database product.

This happens, even now, even with supposed software product firms producing highly technical products. Once it starts to happen, RUN.

I wasn't there so I cannot speak to the particular case. But isn't there an equal but opposite startup death methodology where a purely technical team makes a great product, but doesn't have good market fit, or doesn't have good sales / sales team, or doesn't run the business well?

The techie in my certainly feels like building a great product should be the most important thing. But the ... (experienced|jaded) person in me realizes that's only a part of the problem.

That one does not get a chance to grow, so they don't to fix things by hiring more engineers, and those post-mortem do not get written.

Anyway, if the product is really great, then it must be easy to change it and try to throw at any different markets. It's quite common to see the people caught on that problem to switch into a consulting company that basically install the products for their clients.

I've been around a few of these companies. There's problems with hiring enough software engineers to grow the thing without sales. If the technical solution or team are good enough, this company exits via aqui-hire, otherwise they die too.

The issue isn't that sales people aren't an important part of the business. It's that they have no business running a technology company. I've seen this in an established non-startup with thousands of employees. Tech founder dies and is replaced with a sales guy. PHB madness ensues.

No company exists just to make products. They exist to produce products that will convince someone to give them money. They have every reason to run a “technology company”. All the technology in the world is worthless if no one is willing to spend money on it.

Sounds like they thought they had a solid product and thought they could survive by selling the crap out of it. Not always a bad move.

Looking good, nurturing your coders, relating to beauty and being on time are four cardinal directions that never leave us and go in cycles.

In the 1990s nurturing (or abusing) your coders was priority one for getting results like Ballmer said 'developers, developers, developers!'. We've sprinted through the Steve Jobs 'beauty and thinness' era in the 2000s. We ended up making sure everyone rushes to 'fail fast and often' in the 2010s to get to market on time.

Next up is having a company that looks good on paper and isn't noticeably burning through investor money like toilet paper with no end in sight. Looking good will matter.

After that we will be back to requiring developers to make really good products to get ahead. I wish it wasn't so, but it is. Orson Scott Card tapped into the same stuff when he wrote that article and could probably update it to match today's environment.

Developers, developers, developers! was because Microsoft sold a platform, and the only thing that makes a platform valuable is third party content.

They still sell it, even better, now they sell a couple of them.

And well, they still try very hard to attract developers. They just don't have a CEO capable of shaming himself on purpose and posting it on the internet.

This essay has that tint and feel of the time where programming was an art and programmers read other programmers' code for the beauty of it.

This is when my world crashed hard: when I discovered most employers dont read your past code to decide weither to hire you or not. To me, it's like hiring an illustrator without looking at its illustrations. But asking color theory questions.

> time where programming was an art and programmers read other programmers' code

Rose coloured past?

In my experience, a few decades ago you wouldn’t read much of others code, and you wouldn’t have a folio of previous work you could show a potential employer. Open source or source available hardly existed. You learnt from manuals or books (Code Complete), and you often started greenfield without libraries and did everything from scratch e.g. build using DBase IV, or writing embedded code on a microprocessor starting with nothing. Now you are continually reading code to fix problems in integrated third party libraries, discussing APIs, reviewing PRs, dealing with large team software, and generally having a lot to do with code written by other people.

Shitty programmers were a thing - that hasn’t changed. Amazing programmers hardly ever shared their code with others, because the infrastructure and culture to do so didn’t exist. Things are vastly better today: choice, skill, experience.

Rose coloured past?

I wish you were wrong :)

I wonder though, in specific industries like games for example. I remember in the 90', I was young but when we'd put our hands on some code, oh man we'd jump and read it until we'd get it. Code was rare back then, at least for us. Being able to write code alone was extraordinary. It was a new medium. It was magical.

Btw, my mom used to work with dbase 3 :)

But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, _and worst of all, unattractive people_ who resist all attempts at management.

I feel like this could be a line taken out of American Psycho :D.

If successful software companies are dependent on retaining great programmers, they're probably doomed unless they can keep creating new software. Great programmers want to create. They won't be satisfied with just maintaining a successful product. Few companies have the capacity to keep creating really new products and they certainly aren't going to be willing to abandon the old product.

> Great programmers want to create. They won't be satisfied with just maintaining a successful product.

What about Linux kernel or SQLite maintainers? Aren't those great programmers? Also if the software "they" created is so great, why wouldn't they want to maintain and extend it?

As far as I know, programmers love maintaining great software, but maintenance doesn't mean "bloat it with unnecessary features" or similar. Optimizing performance, make it more reliable, improve the tooling, cutting out the fat and similar are things that are challenging and engaging.

I think programmers want freedom, agency and ownership of something great. Yes, part of that has to be tinkering and writing new prototypes of things that might or might not go somewhere, but it can't be all of it for everyone right?

I lean towards agreeing with you, but both Linux and SQLite do regularly add new features, however incrementally.

Possibly the 2 most popular softwares in the world I’d claim

I agree a lot with your comment. I do think adding new features is exciting, but if a project is technically interesting (like a kernel is), then there can be great satisfaction in maintaining, as that maintenance can be technically interesting itself.

This is not the case if the software is boring from a purely technical standpoint, e.g. some CRUD sales app.

Honestly, there may be great programmers amongst the kernel and SQLite maintainers, but they may stay around for other reasons. Some great programmers like working on a particular piece of tooling.

But many companies don't really allow "maintenance" of software as you describe it - the heady early days where anything goes are pretty free-form, but once you get into the normal business cycle it's just adding features and keeping it from exploding. The problem really becomes apparent when the company has a culture of promoting/rewarding the programmers who do create and ignoring or ostracizing the ones that maintain.

> Optimizing performance, make it more reliable, improve the tooling, cutting out the fat and similar are things that are challenging and engaging.

That's not maintenance. That's later stage creation process. Maintenance is stuff like "make an adapter for foo" or "deal with the format change" or "the new version of windows exposess this bug, fix it".

> Maintenance is stuff like "make an adapter for foo" or "deal with the format change" or "the new version of windows exposess this bug, fix it".

This can nevertheless be quite challenging and exciting: such new requirements often lead to a revision of the assumptions underlying the architecture of the software and thus - in the long term - lead to lots of small improvements in the software architecture that add uo.

The problem rather is that such maintenance tasks are often not very esteemed (both to managers and other programmers).

There's different kinds of great programmers. There's the tourist and the townie. The tourist will only ever get you so far, and you're usually better off without them post MVP.

> Great programmers want to create. They won't be satisfied with just maintaining a successful product.

I personally don't think one can generalize like that. I've worked at companies with great programmers who would've like to maintain and improve things, but end up frustrated by an environment where the incentive is to work on splashy projects because that's what "performing" means there.

I've also seen what you mention of course; the 0 to 1 part of a project is done and people decide to move on. I think it really depends on the person and the project though.

That might be true in some cases but it is not true in general. Most great software has been worked on by the same developers for many years.

dude what?? excellent

> Orson Scott Card (born August 24, 1951) is an American writer known best for his science fiction works. He is currently the only person to win both a Hugo Award and a Nebula Award in consecutive years, winning both awards for both his novel Ender's Game (1985) and its sequel Speaker for the Dead (1986) back-to-back. A feature film adaptation of Ender's Game, which Card co-produced, was released in 2013. Card also wrote the Locus Fantasy Award-winning series The Tales of Alvin Maker (1987–2003).

https://en.m.wikipedia.org/wiki/Orson_Scott_Card

I don't think most people realize that to be successful you have to have the right combination of people including a great development team, great salespeople, great marketers, and great management. Any hole or negative value people in your team and you will not be successful.

And you need luck, you have to have a team that can deliver and a lot of luck.

Most people aren't that good. There are a lot of people that are just so-so and it can be hard to figure who is good and who isn't. That is part of the luck. There are a lot of people that can't handle working with other good people for reasons. There are a lot of companies that build a great team but are missing a critical element and go nowhere or implode.

We worship the survivors thinking that something in the mostly made up story will tell us how to succeed. It will not, they almost always forget about the other great people around them that were just a critical as they were. They always forget how much luck played in their success.

Software companies die because the whole isn't static, the thing that make you successful yesterday isn't cutting it today and most people can't change with the times. Most people never move on from their high point in life and don't understand why things that worked in the past no longer work.

Sounds like an older variant on "The Elves Leave Middle Earth".

A fun read. But seriously let’s stop the whole “developers are ugly/smelly/not social” theme. The developers I have worked with for 30+ years were mostly smart, married or with partners, looked after themselves, and not more ugly that the general population. I have met a few (less than a handful) that were not. But they were very much the exception to the rule.

> someone demands that he PLAN all his programming and then stick to the plan

Even when it doesn't make sense.

I would say this applies to every type of R&D, not just software companies

How Software Companies Die (1995) [pdf] - https://news.ycombinator.com/item?id=15934450 - Dec 2017 (1 comment)

How Software Companies Die (1995) - https://news.ycombinator.com/item?id=12963251 - Nov 2016 (1 comment)

How Software Companies Die - https://news.ycombinator.com/item?id=8860823 - Jan 2015 (1 comment)

How Software Companies Die by Orson Scott Card (1995) - https://news.ycombinator.com/item?id=6818556 - Nov 2013 (168 comments)

How Software Companies Die (1997) - https://news.ycombinator.com/item?id=6182867 - Aug 2013 (3 comments)

How Software Companies Die (1995) - https://news.ycombinator.com/item?id=5372726 - March 2013 (14 comments)

How Software Companies Die - https://news.ycombinator.com/item?id=4776844 - Nov 2012 (3 comments)

How Software Companies Die - https://news.ycombinator.com/item?id=3993706 - May 2012 (2 comments)

How software companies die - https://news.ycombinator.com/item?id=2523005 - May 2011 (3 comments)

How Software Companies Die - by Orson Scott Card - https://news.ycombinator.com/item?id=1866486 - Nov 2010 (45 comments)

How Software Companies Die - https://news.ycombinator.com/item?id=1654310 - Sept 2010 (1 comment)

How Software Companies Die - https://news.ycombinator.com/item?id=1637968 - Aug 2010 (1 comment)

How Software Companies Die - https://news.ycombinator.com/item?id=1635094 - Aug 2010 (1 comment)

How Software Companies Die - https://news.ycombinator.com/item?id=552821 - April 2009 (23 comments)

How Software Companies Die - https://news.ycombinator.com/item?id=99568 - Jan 2008 (1 comment)

Software - How Software Companies Die - https://news.ycombinator.com/item?id=43842 - Aug 2007 (5 comments)

From this I deduce when you mention who wrote it you get more comments.

You can't generalize that from 2 data points! but inner pedant aside, you're probably right that celebrity names have that effect. They're a form of sensationalism and we try to edit all forms of sensationalism out of titles since that motivation set doesn't have much overlap with curiosity.

What motivates developers?

Never being asked when something will be finished.

And make no mistake, I sympathize. But I think an organization dependent on specific stuff getting done at a specific time is the transition to a "mature" environment. This may be why companies that depend on software as part of a broader offering (e.g., hardware) tend to be more stodgy than pure software plays.

Being asked "what blocks you?" by my manager.

TL;DR: failure to understand the production leads to the destruction of intangible assets, while focusing solely on tangible wealth.

Interesting that the author is Orson Scott Card of Ender’s Game fame.

For an author who writes a lot about young children being outcast and bullied, he sure is a raging homophobe. And I don't mean this in a woke way, he's called for an armed overthrowing of the government over marriage equality.

This is being downvoted as a personal attack but I think Card is an interesting case that deserves attention. His books are steeped with empathy and the power of understanding others' perspectives (even alien species!). The fact that he began to attack others' religious beliefs and sexual orientation around the turn of the century is bizarre. I keep his story in my memory as a reminder that anyone can succumb to hatred, the same way I fear my own vulnerability when I read about schizophrenic breaks.

I had the misfortune to read his Empire when it came out, where an evil Soros-like villain starts a robotic blue-state rebellion against a benevolent George W Bush-like president, but is eventually suppressed. Truly deranged Trump-like worldview a decade and half before.

I'm not sure why this was downvoted, Card has openly advocated for gay people to be jailed and fought against marriage equality. A lot of his fiction work also has unflattering depictions of gay characters and relationships.

I want to say "this has really aged badly", but unfortunately this is still how some people see the industry.

10X programmers are definitely real, but can only exist in specific environments. So much of the programming scene on a corporate level is about keeping everything scheduled and regimented, and not producing high quality code

all the 10x devs i know just go to ten times the meetings without a loss in work capacity

I am talking about the negative ways programmers are presented here:

> You can domesticate programmers

> all these programmers keep hearing their fathers' voices in their heads saying "When are you going to join the real world?"

> discover that their product is produced by utterly unpredictable, cooperative, disobedient, and worst of all, unattractive people

> dress [the programmers] in suits, and they become sullen and start sabotaging the product

> you can sense that [the programmers] are making fun of you with every word they say

This is incredibly infantilizing.

Perhaps the tone of the article did not get across to me. Is it written in jest?

I personally read it as serious as I know many people who perceive programmers as nothing more than walking stereotypes.

Unless I completely missed the tone, I still stand by my: "unfortunately this is still how some people see the industry."

Reply on news.ycombinator.com