I think everybody and their little brother has seen Jeffrey and Scott’s posts bashing the MS personas (I still like the name “Elvis” though) and calling for a higher skill level across the board for developers. I largely agree with both posts but I’ve heard it all before. However, Tim Weaver’s response to Jeffrey titled Is Software Development Too Easy struck a nerve with me in a big way. Tim describes an unfortunately common situation in many shops.
From Tim,
My first job at Dell was with Business Systems Management. We wrote the software that Dell IT couldn’t because they didn’t have time. Make no mistake about it, we were Mort’s. We had some above average skills, but we were all just learning. Every company I’ve been at since then has had the same arrangement. There is the official IT projects and then there is the “unofficial” IT projects. The unofficial are almost always done by those dual trade individuals who aren’t professional programmers, but have enough skill to put something out there.
I can very accurately describe what happens with these “Customer Supported Systems” (CSS) because I’ve both built them as a Shadow IT coder and had to take over the resulting CSS systems built by the business. In Tim’s case, I was one of the poor fools in Dell IT that had to take over CSS tools when they became too valuable to not have IT support.
The business spots a need or an opportunity to use some sort of automation to improve productivity. IT can’t do it, won’t do it without some bureaucratic rigmarole, or is perceived to be unresponsive or even flat out incompetent. Into the void steps Mort, armed with a host of Rapid Application Development tools from Microsoft. Mort is probably a Clark Kent type in the business by day, but morphs into Mort when the need arises. Unsurprisingly, Mort understands very well what will provide value to the business because he IS the business. I’ve bashed the RAD mindset before, and probably will again, but they’re undeniably a valuable tool for folks moonlighting as a developer to create business value.
So everything is going great. Mort is a hero and the business gets some value. Then suddenly things aren’t good anymore. Maybe the CSS goes down and the moonlighting developer has gone back to his day job or moved on. Maybe the CSS just can’t handle the load anymore. Maybe the CSS is broken when the underlying systems or databases that the CSS rides on change underneath it. Regardless of the cause, IT finally needs to be called in to support the tool.
Most likely, the tool isn’t written very well. Writing software initially is easy, especially with the type of data aware RAD tools that Microsoft has perfected, but writing software that can be maintained over time is a job for truly professional software developers. So now IT is stuck either supporting a poorly written tool or being tied down doing a rewrite — while the business happily churns out more CSS’s. In a particularly bad case I was peripherally involved with, an IT team had very little flexibility in changing a major application because the business had written so many CSS applications to automate the mission critical manufacturing process that screen scraped the official IT system (just in case your wondering, I’m pretty sure screen scraping is a really bad idea).
My all time favorite story is something that happened to a former colleague of mine. He got to spend about 6 weeks trolling through a 900 page (not a typo) ASP classic application written as a CSS looking for places where ADO connections were not being closed. How in the world a CSS was allowed to grow that large without IT involvement is beyond me. IT ended up in a really bad spot supporting the evolving ASP system while trying to simultaneously replace it with a scalable J2EE replacement. Replacing a moving target most certainly doen’t lead to a high chance of success.
We Have to Be Responsive to the Business
To a point I think the CSS phenomenon is healthy. It certainly leads to a great deal of innovation. The headaches for IT could be headed off if WE could respond to the business’s needs faster and turn on a dime to fulfill emergent business opportunities. In other words, we shouldn’t give the business a reason to go around us for solutions. We can’t afford to throw process and scheduling hurdles at the business. Yes, we’re afraid of scope change but we’ve got to get over it and work in a way that manages change instead of preventing change.
Unsurprisingly I think the answer to the CSS problem is Agile Development. Quoting the Agile Manifesto – “Customer collaboration over contract negotiation.” I think that is typically thought of in terms of third party service providers, but that sentence should definitely apply to internal IT (in our case Engineering) being responsive to and cooperative with the business. Iterative development is a no-brainer. Within reason, the development teams should be able to flexibly change the their workload to accommodate changing business priorities. The typical quarterly or semi-annual release that’s scheduled months and months in advance in a fabulously detailed Gantt chart just isn’t flexible enough.
How Not to Be Responsive to the Business
I worked in a big IT shop with a disastrously poor relationship with the business and a nearly crushing CSS support burden. The natural reaction was to form a committee that was tasked with creating a structural solution to the CSS problem. A couple months later they presented a proposal that involved a complex multi-step workflow for the business to turn the proposal into an actual IT project, i.e. it put more hurdles in the way of the business and gave them more incentive to go around us. Needless to say, the business didn’t accept the plan. Our counter-proposal to form a “swat” team that would be permanently tasked to small customer requests and worked in an iterative process was shot down for some sort of political reason. Nothing improved.
Quick and Clean
You’re free to disagree, but I’m one of the legion of folks that think the traditional drag and drop RAD programming leads to un-maintainable systems. I’m pretty early into my exposure to Ruby on Rails (RoR), but my initial impression is that RoR’s goal of “quick and clean” development that does not sacrifice maintainability for development speed looks like a move in the right direction.
I started as a Mort, just a guy who wanted to automate some stuff for my engineering team. I picked up Access and ASP classic and churned out tools for my engineering group. I quickly found that I enjoyed the automation work far more than being an engineer and embarked on a quest to become a real developer. Not surprisingly, my CSS tools had to be completely rewritten after I left my first job.
