A friend of mine invited me to attend the IASA IT Architect Regional Confrence. It looks interesting and for $150 it’s a pretty good deal. I could probably even get Slalom to cover everything. However, I looked over the agenda and I only saw two items that interested me: “The Myth of Developer Productivity” and “Forecast: Partly Cloudy. How Cloud Computing Can Fit into Traditional IT Architecture”. So drive 6 hours (3 down and 3 back) for 2 hours of content. Worse a quick Google turned up “Myth” as an article. So I’m going to keep shopping. Also, this type of Architecture stuff makes me break out in a rash.
Reading the “Myth” article just reminds me of everything I hate about big organizations, PMI, and other bureaucratic institutions. “Local efficiencies” are bad. Got that? See if I can use Code Smith and ReSharper along with my evil Visual Studio to generate 80% of my client’s needs in three days I’ve just caused a huge problem for all UAW workers further down the assembly line. For shame. They might actually have to do some…..work.
The article focuses on how making developers more efficient isn’t the same as making the over system more productive. It never actually dares to suggest a solution: trim down the team and hire people who are better more flexible developers. Oh no. Instead we get criticism of Visual Studio and tools that provide developers with a lot of leverage.
The criticism is that the developer goes off and ‘hypercodes’ to generate a huge backlog of the testers to test. While the testers work through their backlog the developer proceeds on building on an untested platform.
The problem in my view is this is a completely false premise. Perhaps at NASA or other huge bureaucratic institutions have such a rigid role definition that a developer would never have the audacity to do something as radical as write a unit test for his code. Or perhaps have a buddy or two eyeball it. Or lets get crazy and use a tool like ncover and FXCOP to make sure the unit tests actually test stuff and that our code has been delinted. No that would be heresy because the UAW says only testers test code, only Business analysts determine requirements, only PMs create project plans and *gasp* only architects set architecture.
Right
No. Join me in the real world. Real companies don’t allocate budgets for battalion style development projects. We don’t use card readers to load our applications. We don’t use stencils to draw flow charts before we write code. We either deliver what the client has asked for in something close to their budget and time line or we get fired. Not a Myth. A simple cold hard reality. How do you keep customers happy? Deliver what they ask for, control scope creep, bring change control to the process.
The reason the developer generates the huge backlog for the testers is basause during the time he was working the customer added 3 new features and changed how they wanted 2 of the existing features. The customer didn’t formally allocate additional time or budget but they know it’s there. The developer, at least a good one, is going to try to keep things going so instead of waiting he gets going on the newly created backlog that was handed over. This cycle does 1 of two things: either the developer burns out and becomes an Architect or he gets smarter. He starts writing unit tests for his code. He starts using existing frameworks and builds his own addons for those frameworks. He figures out that if he can generate his entire DAL in 15 minutes with some extra work on those templates he can also get unit tests for the DAL. He figures out that if his WCF service will give up WSDL he can write a template to generate a lot of his basic unit tests or at least have the boilerplate stuff generated. He figures out that using a tool like FXCOP can help spot problems early and a tool like NCover will indicate whether or not his unit tests are effective.
He also starts to figure out that there is a huge world outside of just being a kick ass software developer. He starts to talk directly to the users and customer. He starts learning about their business and learns about things like business processes. He starts learning about project management. He talks to the administrators that support the applications he and people like him deliver. He takes what he learns and he applies it directly to his code. The result is a better, more flexible software developer able to effectively use tools and strategies to deliver to what his customer wants.
This idea however is not even remotely consider in “Myth”. Why? B/c it requires the developer to be more than just a developer and the UAW wouldn’t like that. It also would leave executives questioning why exactly they have these people called “Architects” anyway.