Paying Too Much for Custom Application Implementation

Face it. Even if you have a team of entry-level coders implementing custom application software, you’re probably still paying too much.

Here’s what I mean:

You already pay upfront for fool proof design and detailed requirements.  If you leverage more technology to implement your application, rather than spending more on coders, your ROI can go up significantly.

In order for entry-level coders to implement software, they need extra detailed designs. Such designs typically must be detailed enough that a coder can simply repeat patterns and fill in blanks from reasonably structured requirements. Coders make mistakes, and have misunderstandings and other costly failures and take months to complete (if nothing changes in requirements during that time).

But, again…   if you have requirements and designs that are already sufficiently structured and detailed… how much more effort is it to get a computer to repeat the patterns and fill in the blanks instead?   Leveraging technology through code generation can help a lot.

Code generation becomes a much less expensive option in cases like that because:

  • There’s dramatically less human error and misunderstanding.
  • Generators can do the work of a team of offshored implementers in moments… and repeat the performance over and over again at the whim of business analysts.
  • Quality Assurance gets much easier…  it’s just a matter of testing each pattern, rather than each detail.  (and while you’re at it, you can generate unit tests as well.)

Code generation is not perfect: it requires very experienced developers to architect and implement an intelligent code generation solution. Naturally, such solutions tend to require experienced people to maintain (because in sufficiently dynamic systems, there will always be implementation pattern changes)  There’s also the one-off stuff that just doesn’t make sense to generate…  (but that all has to be done anyway.)

Actual savings will vary, (and in some cases may not be realized until a later iteration of the application)but typically depend on how large and well your meta data (data dictionary) is structured, and how well your designs lend themselves to code generation.  If you plan for code generation early on, you’ll probably get more out of the experience.  Trying to retro-fit generation can definitely be done (been there, done that, too), but it can be painful.

Projects I’ve worked on that used code generation happened to focus generation techniques mostly on database and data access layer components and/or UI.  Within those components, we were able to achieve 75-80% generated code in the target assemblies.  This meant that from a data dictionary, we were able to generate, for example, all of our database schema and most of our stored procedures, in one case.  In that case, for every item in our data dictionary, we estimated that we were generating about 250 lines of compilable, tested code.  In our data dictionary of about 170 items, that translated into over 400,000 lines of  code.

By contrast, projects where code generation was not used generally took longer to build, especially in cases where the data dictionaries changed during the development process.  There’s no solid apples to apples comparison, but consider hand-writing about 300,000 lines of UI code while the requirements are changing.  Trying to nail down every detail (and change) by hand was a painstaking process, and the changes forced us to adjust the QA cycle accordingly, as well.

Code generation is not a new concept.  There are TONs of tools out there, as demonstrated by this comparison of a number of them on Wikipedia.  Interestingly, some of the best tools for code generation can be as simple as XSL transforms (which opens the tool set up even more).  Code generation may also already be built into your favorite dev tools.  For example, Microsoft’s Visual Studio has had a code generation utility known as T4 built into it for the past few versions, now.   That’s just scratching the surface.

So it’s true…  Code generation is not for every project, but any project that has a large data dictionary (that might need to be changed mid stream) is an immediate candidate in my mind.  It’s especially great for User Interfaces, Database schemas and access layers, and even a lot of transform code, among others.

It’s definitely a thought worth considering.

Product-based Solutions Versus Custom Solutions : Tomb Raider or Genesis?

The Product-based Solution is where most of Corporate America is going for IT today.  The talent required to povide a successful implementation (one you actually renew license maintenance on rather than let let quietly die an ignominious death) requires the tenacity, deep specialized product  knowlege (read arcane dark arts), and courage of a cinema Tomb Raider.  The team required has to know the target product as well as Indiana Jones knows Egyptology; with equivalent courage, problem-solving skills, and morals (one can’t be squeamish hacking a solution into submission) to be able to achieve a usable solution versus an embarrassing product snap-in.   In addition to their product skills the team must be able to quickly navigate the jungle of existing applications with their mysterious artifacts to get the proper integration points and data (Gold! Gold! I say!).

What if the team can’t or don’t navigate your jungle of existing applications or do not know all of the idiosyncracies of the product to be installed?  Well you get an Embarrassing Product Snap-In (Do Not Pass Go, Do Not Collect $200, Do Flush Career).  Every seasoned IT professional has seen one of these puppies, they are the applications you can’t get anyone to use.  Usually because the do not connect to anything users currently work with, or have real usability issues (Harry Potter vs. MIT interface).  Yes, the product is in.  Yes, it tests to the test plan criteria.  Yes, it looks like post-apocalypse Siberia as far as users are concerned (What if we install CRM and no one comes? Ouch! no renewal for Microsoft/Oracle, bummer).

Custom Solutions are more like Genesis, Let there be Light! (ERP, CRM, Order-Entry, you get the picture).  It is a Greenfield Opportunity!  The team you need is just as talented as a Product-based Solution, but very different.  They need to be able to create a blueprint of your desires, like a rock star architect for a signature building.  The team needs to be experts in software engineering and technology best practice.  As well, the team needs to be able to translate your user’s meandering descriptions of what they do (or not) into rational features resembling business process best practice.  That was Easy!

In the case of custom the risk is creating Frankenstein, rather than new life (It’s Alive!, It’s Alive!).  Again, every seasoned IT professional has seen one of these embarrassing creations (Master, the peasants/users are at the gate with pitchforks and torches!).  The end result of one of these bad trips (Fear and Loathing in ERP) is the same, but usually more expensive, than the Product-based alternatives.

Debby Downer what should I do?  Reality is as simple as it is hard; pick the right solution for the organization, Product-based or Custom.  Then get the right team, Tomb Raider or the Great Architect of Giza.

Is Custom Development Dead?

Is Custom Development dead? After the last two years of custom development’s nuclear winter, (following 2008s Financial Armageddon), one would think the the Grim Reaper did his best in the blast. I really hope not, designing and building strategic systems make the more mudane aspects of software engineering worth enduring the mind-numbing syntactical pain of creation. Nothing like the smell of napalming the competition with a totally new way of doing business in the morning (my view of “Apocalypse Now” with a business bent). Maybe, just maybe, I hope rumors of Custom Development’s death are greatly exaggerated.

Did Custom Development die of natural causes, maybe pulled off of life support by risk-hating Executive Management as a perverse form of parental control after the financial snafu (Custom Development moves from PG-13 to XXX)?  Off-the-Shelf software products and the ever increasing cost of continuing maintenance really hurt Custom Development as a viable systems choice, but is that enough to put it down? Cloud and “nouveau Cloud” technologies (read SaaS, SalesForce.com) may have provided the coup de grace.  I seriously doubt it, every time I look into the Cloud I get serious PTSD flashbacks to the 70s and 80s IBM Mainframe World Domination (OMG there is a 3270 in the corner!!).  At least there was alot less hype and easier choices back then (Nobody got fired picking IBM!).

It is possible Custom Development died offshore (simple Mickey Finn, bag over the head, Shanghaied and Held for Ransom!)?  While Business Processes and System Maintenance have done reasonably well offshore (Castor Oil of the Corporate world, let Mikey take it!), strategic custom development has had less success.  Quality innovation that can transform a corporation really requires a local team steeped both in the host company and surrounding culture.  Plus, Custom Development tends to have a high infant mortality rate so it is best attempted in short phases supported by an Agile Methodology, definitely not in Offshore’s financial model wheelhouse.  So I don’t think Offshore is implicated.

There is the theory that evolution has spoken and Product-based Solutions have succeeded Custom Development, just as mammals succeeded dinosaurs.  Product companies would like you to believe that, but does that seem plausable (Land of the Lost, Jurassic Park where are you?)?  While Product-based solutions have advantages in success rates and cost, they by their nature lack the true freedom that drives raw creativity and innovation.  Custom Development is that wellspring.

The only thing we have to fear, is fear itself!  Adversity to risk is curbing animal spirits, creativity, and innovation, ….for now.  Custom Development is not dead and will return from its vacation with Puff in the Cave by the Sea when Jackie Paper locks-and-loads and we begin some serious innovation and transformation with strategic custom software systems (BTW thats when the Jobs return too!).