It never ceases to amaze me how often supposedly professional software people (developers, designers and architects) choose to trust in blind luck. They become rabbits in the headlights of pressure be it deadlines, expectation or lack of insight resorting to chucking code out the door as quickly as possible hoping it’ll lead to something good.
If it does lead to something good, how would we recognise it? If it’s going badly, how do we recognise that and formulate a new approach? What is the cost of taking such a speculative action? What’s the best thing that might come out of the action?
Many of these people would claim to be brilliant problem solvers and yet they are lacking grasp of some of the fundamentals.
Technorati Tags: engineering, process, software
Entries (RSS)
Your link to the article about Deming sent me off looking for more information. Wow. Lots of good stuff in that vein of research. Any recommendations on learning resources for starters? Did you read Deming’s books, someone else’s books, etc?
Mmmmm, well much depends on how you learn but a lot of my initial research revolved around the Deming Cycle. I think of the books I’ve read I’d pick:
Out Of The Crisis – Deming
Why Things Go Wrong: Deming Philosophy in a Dozen Ten-Minute Sessions – Fellers
As we’re talking philosophy, the tricky thing can be understanding how to apply it. One of the things I focus on a great deal these days is ensuring that I can measure and grasp the problems I’m dealing with. Note for example how much software goes out the door these days with little support for useful measurement – the closest one typically gets is to dig through log files such that when things aren’t working right or you need to re-design the information you’d like to guide your efforts is seldom available.