> Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it.
I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so.
I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job.
> It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.
Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.
"I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so."
Indeed. I watched three people say "no" to a significant, new piece of very important software that replaced completely our legacy data storage/fetching/processing methods. They said "no" for the reasons you'd expect; not properly specified, unreasonable expectations of basically magic on the part of management, very improbable timescale.
In one meeting, when a very skilled programmer (who goes to the C++ committee meetings and that sort of thing) said "no", the response was "Well then I'll find someone who can." What they got, of course, was someone who didn't say "no" (and of course, there's an element of self-selection here; given that some skilled, competent software engineers said no, the person who said yes was, harsh as it may sound, an adequate programmer but an incompetent software engineer). What we got was a total car crash of software, six months late, that's massively unsuitable, doesn't do what's needed, undocumented, untested, everything bad that you'd expect. A great deal of the 40 "release candidates" were desperate fixes to this car crash, that our recently appointed new software architect is planning to take outside and execute in the car park as soon as we get a "release". So that was a great use of a year.
Where this is going is that saying "no" didn't actually stop them finding someone who wouldn't say "no". On the plus side, the person who delivered this truly atrocious software to us is now actively looking for another job. Not that he was fired, no no, but he's now got zero credibility and nobody wants to work on anything he ever touched.
Because he's not taking the godawful software with him. That's staying.
It's also a problem for me because he's done his damage. I want to make high-quality software, on time, that does what the customers need. I want this out of both a sense of personal pride, and also because I need the company to keep making sales so they can keep giving me money.
I don't run the company, and even if I ignored everything I was told to do, and didn't get fired, and instead followed sensible, professional processes, I don't write the entire software by myself.
I am bemused that someone of your experience has trouble grasping this. I thought perhaps you were some kid straight out of school who thinks the whole world works like the marketing material for agile, but it turns out you've got a decade of experience. You must, surely, have seen (or at least heard of) companies that don't look like the marketing material for agile?
Sure. Mostly when I see it, it's people who don't know any better. With a fair number who do know better but do it anyhow. The former group I understand. But the latter is a mystery to me.
I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so.
I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job.
> It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces.
Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.