That, my friend, sounds a lot like The Cat Ate My Source Code [The Pragmatic Programmer]
Price, lead time, quality, (and scope) — pick any two. When the stakes are high, don't rely on your manager to pick quality — that is your responsibility.
And if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.
> if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.
I did this and while it solved my moral dilemma it made things worse for our users.
Many years ago I started my career working for a startup that got bought by a big government contractor. The most incredible people I've ever worked with tried harder than you can imagine to deliver reliable, usable software for the American taxpayer that met the very high bar we set for ourselves.
Because the incentives weren't aligned, most of the good people eventually quit to work at places where they could deliver something that met their bar and were replaced with junior devs and senior clock-watchers.
Every good person who left made that problem slightly harder for those of us who stayed because there was one less person fighting for quality and usability, but the contracts were as big as ever and the new people were less likely to rock the boat so management didn't care that product quality was dropping off a cliff.
In the end it was primarily our users who suffered.
> [--------] didn't care that product quality was dropping off a cliff.
fill in the blanks! it's not management, it's the customer. if the customer doesn't care management doesn't care.
it's a tragedy, but it's what it is. citizens as users need to demand better. it's just politics. in the end revealed preferences show that users don't care that much. they learn the shitty system to do their thing, and then they go home to their family/dog/MMORPG/life.
and users don't care on the meta level either, to have better procurement processes.
You're right, management was simply the messenger relaying customer priorities.
I will point out that enough consumers are willing to pay for a quality products that many niche companies exist to serve them. Many citizens choose to move to countries/states with better services even if they have to pay higher taxes. There are employees who reject higher-paying jobs that require interacting with poor-quality software or processes. (I work for a niche company that makes and uses high-quality products in a high-tax / high service state so I know many people like this!)
> citizens as users need to demand better.
I get what you mean, but as you point out many people's revealed preferences show that they don't actually want quality in which case they already do "demand better" -- it's just that for them "better" means cheap, fast, and convenient.
> [..] were replaced with junior devs and senior clock-watchers.
That is a sad story indeed.
I guess the silver lining is that you didn't waste your talent contributing to a mismanaged project. Hopefully, given a free market, the service will eventually be replaced by something better.
I don't regret the decision but I do feel a little guilt for what I left behind.
I have friends who moved out of struggling towns and states who describe similar feelings about being part of the "brain drain" death spiral that is hollowing out the place they grew up.
> Hopefully, given a free market, the service will eventually be replaced by something better.
I too believed that something like that would happen eventually but their business is still booming. In the decades since I've learned that the "fitness function" of companies that serve governments or large enterprises do not reward product quality (at least not commensurate with the cost of quality) so companies or teams that insist on wasting effort making quality products do not survive. It's not malice or incompetence, it's just a survival response to misaligned incentives.
Felt the same when saying goodbye to my colleagues, stranded in a golden cage, when the startup we worked for was acquired by Oracle after 8 years. Our beloved product was eventually killed (years after I resigned), but Oracle — despite its obvious mediocre halo — is still alive and kicking.
This is a fair point. If the only agency you have is the choice between following marching orders without questions, or unemployment — don't quit.
But I would be surprised if this is the way all EMR software is built. Software development being a creative process, there should always be a feedback loop where managers ask open questions. There lies the agency to recommend spending more time and money, reduce scope in order to guarantee a level you feel comfortable with. You may not get what you bargain for, but it's up to you to decide if it's enough.
Taking the money in return for doing the work is a way of telling your boss you're on the same page. Given your medical context, that may not mean you fully agree, but it evidently means you accepted it.
And then we have about 90% of working sw devs quit tomorrow - it sounds great but people are not going to leave when they know the next place is basically the exact same.
I beg to disagree. Although I've only worked for European and US companies, my experience is that even bossy bosses appreciate quality design and understand that lack of time, pressure and exploitation cause products to degrade. But pressure can only exist if there is an equally opposing force — you, me, us.
If my recommendation to bluntly quit sounded harsh, I'm happy to tone that down. There is value in compromise, but just make sure your voice is heard, say no if you cannot / will not do it in such little time to the extent that you feel is required. Fighting for the time to do our job well is our struggle. Sometimes it's easy, more frequently it's hard, but when it's simply impossible — have your boss find someone else.
Quality — at least internal quality — is primarily the responsibility of the software developer, not her/his boss or some QA department.
I don't think it sounds harsh, and I have worked with dozens of tech companies and directly for a dozen or so - the only one that wasn't obsessed with cheating out on quality to make a buck was bilking his customers so much that he didn't care.
At every phase of the conversation is management saying they have this hard deadline and
I have been fired multiple times for being too vocal about the failures of process or technology, though mostly I just get ghosted for pushing back when things are unreasonable, at this point I exclusively go for visualizations, gantt charts, etc - to communicate that the timelines are not possible with the current investment in the team/tech/whatever.
I just got laid off for (as far as I can tell) being the person who kept asking the question about why we were doing a thing that provided no technical or business value for a year, and in most of these cases some exec thinks they know best because they read some magazine equivalent that tells them this is the new hype revolution.
Basically if you can find some highly skilled or highly profitable company that's concerned about losing their edge you might be able to do this, but your next boss might change the entire equation.
If you quit, they'll just hire someone who's willing to do the crappy stuff. As a bonus, they'll probably pay less for that person. Or they'll spread the burden over the remaining staff. Or they'll outsource the whole team to some remote hell. Quality is not a bottom-up thing, everybody has to be in on it.
Most management will exchange quality for quick gain whenever they can because they're there to make money and don't plan for long term. Because they can also leave the ship when the sum of their mistakes starts to sink it.
> Quality is not a bottom-up thing, everybody has to be in on it.
I like it. But I've seen at least one place (a start up) where (to some extent) quality was a bottom up thing. Eventually it became a share value, but it was rooted in developers saying: No, we need more time.
On the other hand, I don't know of examples where quality was forced top-down — places where a senior developer would say: I'm done/I don't care/this is good enough and their manager telling them to spend more time on a feature or teaching them about software design.
Ah yes, rogue quality enforcement, I've done it too. It's all fun and games until some nosey manager questions the overeager developer who naively lets them in on the scheme and thus exposes the whole team for the bunch of non productive rebels that they are and then it's back to square zero.
Quality conscious management doesn't impose strict rules themselves but rather maintain a climate of mutual trust between business and technical where constraints and problems can be surfaced, discussed and addressed openly. Respect for technology is sorely missing from the business class curriculum, yet so much depends on it.
