Do most companies not know how to write software?

Question

If you're an active reader here, try to think about how many times you've heard (and even agreed) when someone here has told someone else to start looking for a new job. Personally, I've seen it a lot more than I expected: it's almost starting to sound cliche.

I get that there are bound to be a number of companies that are bad at developing software or managing a software project, but it almost seems like it's getting worse and more frequent, maybe we're just hearing from them and not all of the places that have decent work atmospheres/conditions.

So I ask:

In your experience, and through your developer friends do you find that it is common that companies have bad development environments and if so:

• Why do you think it's common?
• What do you think could be done to fix it as a developer, as a manager, as an industry?
• Do you think it's improving?

Answer 1

Is it true that most companies don't know how to write software?

Yes, it's true. Most companies don't know how to write software.

Why do you think this is the case?

Most software companies hold their development teams accountable for two things: Cost and Time to Market (TTM).

Regrettably, most software companies don't hold their teams accountable for Technical Debt.

This leads to a quagmire because:

• Increasing levels of technical debt increase the difficulty of bug fixes and new features.
• Which increase cost and TTM.
• Which leads management to crack the whip and demand unpaid overtime, because the development team is failing on its two key metrics: Cost and Time to Market.
• Which leads to more Technical Debt!

What do you think could be done to fix it as a developer, as a manager, as an industry?

Two things:

1. Management needs to understand and account for technical debt.
2. The software industry needs its own equivalent of Harvard Business School (HBS). Managers need to read software-specific case studies about project failures and learn from past mistakes. Right now, managers emphasize cost and time to market because that's what they know how to do. Software projects have their own nuances, and it's high time that we manage them accordingly!

Do you think it's improving?

No - In the aggregate, I think things will have to get worse before they get better.

Answer 2

I see this as a pattern in some start up companies. I'm not saying that all venture capital is bad, however the pressure it buys you is directly related to the patience of your investors. I think that the "just get it out the door" mind set kicks in and really bad practices and environments follow.

When under serious pressure, people are told to:

• Work much longer hours
• Skip stuff like writing tests
• Not bother with continuous integration
• Not worry about formal specifications
• Delay re-factoring code until it explodes when anything new is added
• Write documentation 'later'
• Accept punishment for delivering late instead of incentives for delivering early
• Trust that five new programmers on the team will help at the last hour
• A whole lot of other badness

Investor micromanagement (often using CEO's / CTO's as proxies) is also a major issue for many. This is one of the biggest reasons that I avoid VC funded companies that have yet to turn a profit.

Stack Exchange is one of the few exceptions, they seem to have rather patient investors, and was founded by a core of really good people who know what happens when you don't do things correctly the first time.

Still, in my experience, well organized VC funded start up companies that provide positive environments are more the exception than the norm, and I think we're seeing quite a bit of evidence of that here.

On the flip side, you really don't hear people talking about how great their jobs are, just like you don't hear about the millions of uneventful car trips every hour. You just hear about the wrecks.

Also worth noting, 'venture capital' can also mean micro finance in some situations. The pressure doubles when 'investments' come from savings or retirement accounts. This usually also means the company is running on fumes.

Answer 3

"A company" knows nothing about writing software. People know how to write software. Problem is, most companies don't employ management who know how to effectively find, hire and retain people who are good at writing software.

Answer 4

I have found throughout my career that most companies are so inept at what they do, they remain in business only out of spite for their employees.

Obviously that is not true, it only appears that way. This is because you will always have the strongest opinion about things that have the most direct affect on you. While no company or department or team does everything perfectly (and some do come closer than others), it is simply perspective that makes you believe that your company is the worst at "x".

Answer 5

Yes, crappy development practices are quite common.

Why? Management sees software as a car. Doesn't matter what's under the hood as long as it moves forward. So if software runs, why bother improving it? We all enjoy visiting different websites every day, not even thinking wheter software running it is state-of-the-art or kittens-killing-nightmare.

What can be done about it? Well... from my personal experience it appears that competition is the key. Only when some other competetive company can do something better/faster management starts asking questions "why?". And even when they start with wrong decisions (more workload, layoffs) they eventually come to conclusion that they have to improve software development process in order to stay competetive.

Is it improving? Yep, albeit quite slowly.

Answer 6

Yes I think it's common because many companies aren't pure software companies like Google or Microsoft.

Many will have an IT department where software development takes place, and many developers will work at such companies. These companies write software to support whatever business they are and they will write it badly and in anyway so that their business survives. Most will not appreciate or care for good software development methodologies, the latest tools and technologies, nor finding talented developers and treating them well.

I'm not sure I formally believe in any "fix". I believe more in general improvement of developers, managers, and the industry as a whole in how everyone does their work and shares what they know. Community and education is how to improve the world of software development. Books, user groups, online communities, etc.

Yes, I think it's improving. This thing called Agile is getting more and more popular. TDD is getting popular, hopefully to become a standard everywhere. Frameworks are getting better and better.

Whatever problem we are trying to fix, a developer is creating a solution for in a better way. Whatever problems arises from that, someone is fixing too in some way. All very recursive.

Answer 7

I think a lot of it is just not having a clue. I interviewed a few years back at a startup, I asked them what source code control system they used. The CTO said "What's that". It went downhill from there! They made me a decent offer, I turned them down. (I spoke to a friend, his office scored a 0 on the Joel test!)

Even my current place scores only about a 4 on the Joel Test. I think a lot of it is an education system. A lot of this stuff like (CI) is not taught in university. Or many managers are old enough to have graduated really before things like CI came onto the market.

Answer 8

First of all, I think there is a sampling error here -- people are much more likely to ask a question when/if they run into a real problem. Chances are that before they ask here, they've already tried to solve the problem(s) in the relatively straightforward ways. Truth to tell, for every question that gets asked here where people reply with (some variant of) "find a new job", there are probably 1000 similar questions resolved without any difficulty at all.

Second, I think in a lot of cases, software is almost incidental the reason for saying somebody should get a new job. Just for example, I recently said (or implied) that somebody should get a new job because he asked about how to hide what he'd done from his coworkers. In this case, the "work he'd done" happened to be code he'd written, but my reaction would be essentially unchanged, if it was something else entirely (e.g., he designed houses or cars or airplanes, and needed to hide his designs from his coworkers).

Answer 9

What you're not finding here are people indicating that they were put into situations where the management "claimed" they would except bad software for whatever reason, and then fired developers for not delivering quality software.

Those willing to take on technical debt don't have the ability to calculate the amount. Maybe ignorance is bliss?

Too often developers are told this is what a good job should be like (Joel Test?) but aren't challenged to fix it. Does upper management really care about source control, testing, documentation and any other kind of best practices?

The problems developers or developer managers have is when confronted with the question, "How long will it take?" we assume they mean, "What's the fastest can you deliver?" Instead of considering all the short-cuts and ignoring quality software we try to please. The sooner we stop falling into these personal traps and give honest answers to these requests, the better our jobs will be.

Answer 10

I'm not sure if this is true for everyone, but the few development companies I've encountered have started off by someone seeing a need for a good software solution within their industry and building it. Once they do that, they feel they are qualified to build software for other industries, and a business gets formed.

Also, I think that most software companies start of small and when there is only a handful of programmers working on each project, they tend to ignore things like source control, code review, industry standards, etc providing their partners are OK with it

I'm not sure of how to fix it because there will always be terrible companies out there, but having an online resource for how a software company SHOULD be run (and why) is a huge help. Sometimes all you need to do is point the person in charge to a reputable article and they'll turn into a believer

Answer 11

Most companies are not in the software business*. For them, software development is a necessary expense, not a strategic process, and therefore they don't pay as much attention to it. Such companies tend to go for the safe solution (currently Microsoft, used to be IBM), and their software development practices tend to be adequate for what they do, but hardly good.

Many companies in the software business are relatively new, and have grown rapidly. Software practices that will work well enough when it's Fred and Joe sitting back-to-back in a small room frequently don't scale well.

Also, software isn't really like most other business processes. It's design work all the way, requiring some creativity in virtually all aspects. It's much more similar to graphic design or making building plans than it is to accounting or any sort of manufacturing. There aren't a large number of people who went through the business doing things in a modern way (say, with distributed version control). Not that that explains why so many companies could learn things from Brooks' "Mythical Man-Month", but there's still some unfamiliarity.

*By "in the software business", I mean a company that relies on software as a central and vital part of the business model. This includes companies that sell software, and also companies that sell goods and services through a process that heavily uses custom software for a competitive advantage.

Answer 12

When unexperienced teams become too obsessed with quality/process etc., they stall. They cease to produce anything, and instead have endless meetings and discussions about which process is better, how much detail should go into the specs (usually: the more, the better), which indent style is the One True Brace Style etc. A lot of cargo cult is involved in those discussions.

Then the project dies. Or a manager cancel all that discussion and tells them to just create anything, not regarding quality at all.

Answer 13

Why do you think it's common?

Economics

What do you think could be done to fix it as a developer, as a manager, as an industry?

Understand that there are economic influences at play and then try to do your best within the economic constraints that are placed upon you

Do you think it's improving?

No. I think it will always be a problem. It's our job to make sure we do the best we can with the resources provided

When you're working for a company quite often the goal is to produce and sell a product or provide a service and the IT systems are just part of the business infrastructure to do this. I think programmers also have to accept some responsibility for shoddy development practices.

Answer 14

Depending on your definition of "write software" and "good", knowing how to write good software (of any significant and useful complexity, which is increasing at an high rate) may or may not be within human capability.

Being able to write software so much better than everybody else that most of them think you are good at it is possible, but obviously only applies to outliers in the field. It's also a moving target.

Since most companies/managers don't manage software as something nearly guaranteed to fail in some manner, they fail.