Developing Error Opportunities

I'm never able to catch myself making a coding mistake before it happens.  The funny part, for me anyway, is after the fact when I discover what the issue really was — it was a trivial error.  And the pattern I followed leading up to the error was avoidable.  How could I not have seen this coming, I sometimes question.  Is the answer that only in hindsight are these types of things obvious in an activity as complex as writing software?  That may be the answer.  But even still, I think it is both interesting and worthwhile to think about this type of software development pattern.  What makes us predictably and repeatedly successful, and what makes us unpredictably and repeatedly error-prone?

Corporate Coding

In an interesting entry over at coding horror, we hear about the idea of "happy talk" and the general corporate stench that accompanies it. Happy talk is the type of corporate language employed that masks anything realistic that may actually going on. So why is this necessary? Obviously not everything that goes on at a company needs to be portrayed literally and it never is. The stakeholders need to be happy. Hence the term. If the company isn't placed in an overall "happy" light, all isn't well and people become upset. The news is, all is not well and never will be. Especially in software development, things just simply do not go as planned.

So what kind of effect does this "happy" corporate culture have on the software development effort of a given organization? Does the this bogus lingo spill over to the software development culture? Not always, at least not on the same scale. But sometimes it does.

So take some developer working in a large company for instance. This developer is in change of developing and maintaining some component in a complex system. Any developer is going to experience the stresses involved with deadlines. The stress arises because they need to make compromises that lead to not so high quality code, that is potentially buggy. But if he knows this component looks good on the outside and works "well enough", no harm done right? He'll just continue collaborating with the other developers as if all is well. This in itself would not be very damaging but what if scenarios like this are continually repeated?

It would be nice if all environments were like some smaller shops and developers could fearlessly admit to flawed code. The company in turn would in turn say to the concerned parties something close to what is actually happening. Doing otherwise sets the stage for upset customers down the road when things really go wrong.