Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Mort + RAD == Business Value Now && IT Headaches Later

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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • John Teague

    Thedailywtf has a post about the “shadow” developer.


  • http://www.bellware.net ScottBellware


    > You allude to this with your comment on ROR, but maybe language
    > based products isn’t what we should be pushing on these guys

    Although the language provides for some interesting design opportunities, it’s the Rails framework that completes the picture. RoR isn’t merely a language-based product or solution. Raw Ruby might be such a thing, but I don’t believe that bleeding edge software people are singing the praises of RoR to merely promote the language as much as the emerging properties coming from the language in concert with a contemporary framework.

    > probably something more graphical like workflow tools

    Which is not much more than a RAD environment for business process. If visual assemblers haven’t led to the successes promised by companies like Microsoft for relatively simple stuff like data entry screens, then why do we expect it to work for something inherently more complicated like business process?

    The challenge to sustainability has never been the ability to generate new chunks of automation. The challenge, the risk, and the cost are now as they have always been – maintenance. RAD is about creating initial versions of new products with little regard to sustaining these applications under the exigencies of change forces.

  • http://subdigital@gmail.com Ben Scheirman

    “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” …

    I once saw an ASP app (not quite that big) that recognized that they could utilize COM to clean up the ASP code and reuse functionality. But they knew nothing of object desing (inheritance) and decided to use Copy-Paste to create over 200 very similar COM objects. Yuck.

  • http://dotnetjunkies.com/weblog/johnwood johnwood

    Whether you call them ‘customer supported systems’ or user-hacks (as we do), they are indeed pretty rampant in the workplace. Nick Malik posted something yesterday about how decommissioning applications that need to be integrated into the ‘bigger picture’ is often as expensive as writing the thing in the first place.
    There’s definitely some validity to that. However I’m not sure I would want to discourage those business experts from getting their hands dirty and producing solutions, because those solutions do serve a purpose and do provide value. I just think they’re using the wrong tools. You allude to this with your comment on ROR, but maybe language based products isn’t what we should be pushing on these guys – probably something more graphical like workflow tools. Harnessing their creativity is key I think.