When the Student is Ready, the Teacher Appears

I remember hearing from a 'higher-up' once at a previous company that we shouldn't do Use Cases.  "The customer doesn't like them", something I never heard directly from a customer. Doing a design review with use cases, a domain model, and a set of fleshed-out sequence diagrams was once described as 'over designed'. It was a mystery to me at the time why they would be so ambivalent about better ways to develop software.

Now, in my graduate class at UTA on Software Design Patterns, the assignments are ironically familiar:

• project requirements
• use cases (3 levels)
• domain model
• sequence diagrams, design class diagram
• pair programming
• test driven development

Not even ten years ago, these practices were still gaining acceptance in the industry.  A common complaint up until now has been that colleges and universities don't teach these techniques, which only gave the critics more ammunition.  Now that has started to change, hopefully the debate about these practices will be about how to best implement them instead of how to dismiss them.

It turns out that the solution to the mystery had nothing to do with the merits of any software development methodology but rather had everything to do with the rejection of in-house software development. This company had a long history of developing their own software and over the years had ended up with one of the largest technology departments  I've ever worked in, close to 1,000 people.  When the leadership changed, the attitude shifted from "Not built here" to "Don't build it if you can buy it".  They didn't value the capability to develop software, so trying to improve the process had become moot. Preferring to buy vs. build is a perfectly reasonable approach.  Some company's realize they don't want to be a development shop and make no bones about it.  The harm comes when there is a disconnect between management and the teams doing the work.  Psychologically, this would fall under cognitive dissonance; having a development shop mindset at the same time the departments actions are turning away from development.

It wasn't a surprise then, when it was announced that they were 'partnering' with a large three-letter company to rewrite their web-site, which happens to be the company's main source of revenue.  The team that developed the site was held in high esteem by the department, full of some of the smartest guys and pushing the envelope, all while supporting a truly business-critical app 24/7 with close to zero unscheduled downtime. The site happened to be written in C++, putting the bar high for development skills for recruiting. One of the clues to the mystery was at a monthly meeting of technical leads prior to the partnering decision.  Using C++ was being de-emphasized, the reason given was the difficulty in finding qualify developers.

The interesting question becomes, if you devalue software development skills will you lose the ability to monitor your partner and be a fully engaged partner?  Inevitably, you'll have to take some consultants word on a technical matter and you'll no longer be a partner but rather a simple client.  Keeping your organizations software development skills sharp benefits you even if you don't write the code.