If your expectations are not shipping with many bugs and avoiding serious blow ups then yes that's a fine way to do things. And if we're happy relying on a single SWE (what happens if you get hit by the proverbial bus?) then yes that's fine too. And if we never need to scale then SSHing into 100s of boxes is fine too.
Most of my job is replacing stuff like you describe. And it's definitely not fine. Nobody knows how it works because that single SWE is gone. It can't scale with the business and it's a huge drag on productivity because nothing can change without a massive testing effort to ensure it's not broken.
Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?
In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied. Ironic given that the other engineers I worked with were MEs, who had notebooks full of processes describing how they were to work so that engineering issues would be caught. But the software? "I don't care how you do it, just ship the feature"
As an aside, I've always found "nobody knows how it worked because XXXXX is gone" to be kind of funny: the code knows, so go read the code. It'll mean everything takes 100x longer but the knowledge is there.
> In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied.
My approach to that is to not ask, just write the unit tests anyways, ask a peer to code review without management permission, etc.
We are professionals. Part of that responsibility is to know the best practices for our craft and put them into practice.
We also need to be good at getting the requirements from the technical and non-technical people we work with, and being able to show consistent, incremental progress, and a willingness to quickly change direction when the requirements change.
But we do not need to get input or permission for the process we use to produce those results.
> Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?
There are plenty of SWEs that just don't know any better. I know because I was one of them while writing a lot of software for a business.
Most of my job is replacing stuff like you describe. And it's definitely not fine. Nobody knows how it works because that single SWE is gone. It can't scale with the business and it's a huge drag on productivity because nothing can change without a massive testing effort to ensure it's not broken.