We’re not a software shop. Yes, you are.

One of the things that has bothered me over the course of my career is hearing statements like this:

“We’re not a software shop. We just make <product here>.”

The typical scenario for a statement like this is the “justification” of cutting corners on software development:

Since the company really does not develop software, it’s okay for all the other departments to come up with a project plan and how long it will take, then hand that date to the software development team. Never mind that the deadline is not enough time to produce a quality product; it’s just the software piece. It’s good project management to make the software team hurry and hit the deadline.

What’s worse, programmers even use this excuse. And the business loves that.

That is, until the business finds itself mired in constant support, production problems, using unreliable data, and feature enhancements taking longer and longer to complete. The business can think of their situation in these possible ways:

* This is normal. This is just how software development works. We have a lot of production issues, but our team works hard to constantly keep it running.

* The software development team used to be fast and good, but now they’re slow and write a lot of buggy software. They must not care as much as they used to. We need to push them even harder.

* We must have been approaching software development the wrong way. Let’s stop and analyze why things are this way, and see what we can do to develop software the right way.

That last bullet point is rare. Why? Because only companies that “get” software development would ask those questions. And those companies would have done it correctly in the first place. It can happen, though, if enlightened employees are hired during this process.

The first bullet point is an unfortunate situation. Things could be better, but no one sees it, and the business keeps moving, albeit at a slower and slower pace. This is just how things are.

The second bullet point is tragic. The software team has put themselves (yes, it’s their fault) in the terrible situation of having to hurry and create bad software, and for their efforts they are now not trusted by management. They’ll typically spend nights and weekends (and early mornings) fixing things, and adding new things, because that’s what it now takes to keep things running. And many times the development team will do this covertly, because they don’t want management to know that yet another problem occurred. In the end, the software team gets burned out trying to keep up this pace, or management replaces them with offshore developers.

When your company depends on the software that it writes to keep things running and profitable, I hate to break it to you, but you are indeed a software shop. You’re just not admitting it.

Deadlines as excuses for writing poor quality code? No.

Someone said this to me:

"We never get a chance to clean up ABC code or to refactor it.”

My reply:

The business will never explicitly give you that time. It’s up to you (indeed, all of us) as professional developers to not use deadlines as excuses. There is no deadline in the world that should cause a seasoned developer to duplicate code. It’s up to us, with a commitment to quality, to push back when we’re told to hurry. If we don’t do that, who will? It’s professional negligence to use deadlines as excuses. Most businesses think they have done good project management work if they get the developers to hurry and produce the end result more quickly. They don’t realize how much they’re hurting themselves in the long run by sacrificing maintainable code.

Many times deadlines are arbitrary guesses that folks came up with at the beginning of a project. They’re meaningless. They’re actually worse than meaningless because being forced to hit them is detrimental to quality. It’s okay to let the business know that the work won’t be done “on time.” Many developers think they’re trapped into hitting a deadline, when if they just did quality work, and explained the situation to the business, the “deadline” could be moved, or code could be time-boxed. Sacrificing quality, to the degree that I’ve seen in ABC code, should never be an option.