“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.
* 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.
No comments:
Post a Comment