Dealing with mistakes in a resource constrained environment

Question

There's pat advice about the recommended practice of code review/pair programming, allocating budget for testing, writing unit tests, using design by contract, and on and on.

Some environments are so resource constrained or historically idiosyncratic that practices like these are not welcome as suggestions. For most of my working life, I've enjoyed the luxury of upfront design, a dedicated QA resource, and code review. For now, it's a fond memory, and I believe it has lead me to a mindset that devalues careful and decisive behavior in certain situations.

I've now made my first real mistake (one that was found early thankfully, and for which I was able to quickly repair), and I'm wondering how to gauge its fallout in advance of having the full experience of being managed out. I'm taking the position that this is a fairly unforgiving environment, where trust is earned only very gradually, and lost very easily and quickly. I also hope that I'm not being unrealistically paranoid.

This is a situation the crops up over and over, I'm sure, and it's to be cherished for its delicacy/complexity and for the lessons in life that it teaches. Would anyone be willing to share their own war stories from such scenarios?

Answer 1

A work environment that is seriously resource constrained, not interested in quality assurance, and unforgiving of errors, is an evironment that is a setup for failure. If you decide that this is the kind of environment that you're in, it's time to start looking for a new job. Be ready to answer the question "why are you leaving your current job?" without trash-talking your current employer. It's also good to develop your own questions to ask on interviews to try to detect a bad work environment.

Good interview questions for you to ask would include probes about working hours, development process, how deadlines are handled, what the process is for moving from development to production. I particularly like asking about quality processes and change management, and asking these questions to every person I talk to in the interview process. These are very good questions to help expose the overall work environment. (e.g., if you get radically different answers from each person, they have no process).

It also helps to know what you want in a development process and work environment. If you currently have a job, or you have a sufficient cushion to handle a period of unemployment, it's really valuable to feel that you can turn down a job if something doesn't look right or feel right in the interview process.

I had a situation similar to yours a few years ago. The interview was a group interview, so I didn't have a chance to compare answers on questions. However, no one in the interview seemed to have any enthusiasm for the job. I walked out thinking that I wouldn't get an offer, but I was wrong; I got an offer, and because nothing else was on the horizon, I took it. My gut feeling was right, though, and I started looking for another job almost immediately, which is definitely not something I would normally do. Beyond the very poor code quality, all developers were expected to give estimates on small changes and very poor requirements, with little time to investigate. If you missed an estimate, the manager took it personally. It really wasn't much of a wonder that morale was so bad that I could pick up on it in the interview!

So, yeah, if the job is really not a good fit for you, better to figure that out early and start looking.

Answer 2

There is no silver bullet: if you have no resources to "spare" for high productivity techniques that reduce errors and/or catch them early (all the litany you list, plus a few more such as continuous integration, and IMHO minus "big design up front" with is neither high productivity nor really compatible with best practices such as TDD), you'll definitely not have the resources to deal with the errors that inevitably come up (nor for ever paying back the horrible "technical debt" you're accumulating by skimping on testing, etc, etc) -- eventual disaster's more or less guaranteed (such situations are a big part of why a vast majority of software projects are failures).

"Never make any mistake whatsoever" is clearly not a realistic policy prescription: "to err is human" is just as true today as it was millennia ago when the phrase was coined (there's no Humanity 2.0 to upgrade to, I think). So preventing and mitigating possibly-disastrous consequences of mistakes that aren't caught in time is, literally, the best we can do. To repeat: no silver bullet!

Answer 3

Done right, code reviews/paired programming/proper QA are indispensible tools that produce better software with reduced development time. I think you know this, hence your question.

If you're an individual contributor, start calling your coworkers over to your cube/office for code reviews and paired programming. Whether or not your management ever "gets it" shouldn't stop you from proper software development. If your manager is upset over you spending an hour in review, demonstrate the bugs you found that would have otherwise been missed. If that doesn't help, good luck and start polishing your resume.

I work in a fast paced environment with aggressive deadlines... but experience has taught our team that skipping the basics always causes schedule slip and more defects. Hope things work out for your team and best wishes!