Gartner’s forecast of a 75 percent BUILD-NOT-BUY rate for digital business applications raises the question of how IT executives keep their hard-won seats at the table. The success rate of software development projects hovers around 65 percent. That’s an F.
No matter who is doing the building—in house or appdev vendor, the buck stops with the IT leadership. Even if they can get all the money back for a dev project that’s gone south, they can never recover the wasted effort, lost time, and tarnished credibility. It’s a disaster.
One of NWN’s good customers—let’s call it TransAct–uses a process that we believe others might find valuable. In the midst of a major development project, they asked us for a code review. Frankly we do our own code reviews as a matter of course, but we rarely get this request from a customer. We believe more customers should be asking.
Some background… The system TransAct has asked us to build for them is a web-based system that allows an audience of about 2 million people to conduct business with them on the web and also through mobile devices. TransAct timed its request for the code review perfectly; we had completed the architecture and were in the middle of coding the 50 transactions that are going mobile.
TransAct sent a technical team to spend a day with us in our offices. Our senior technical team first reviewed the system design to set the stage. Then they went through the code, architectural layer by layer, to show how each part of the design was executed. (Bragging here: this review was scheduled with little forewarning, allowing us to show that we develop resilient, maintainable systems even without this kind of oversight.)
As a direct result of the code review, TransAct understands and approves of the actual system architecture, not just the design. They are confident it will work as expected and their team can support the system when we hand it off to them. Most importantly, they see that it will give them the flexibility to handle whatever comes over the transom. The IT leadership will not be going back to the capital committee for money to replace the system any time soon. Neither will IT appear as a roadblock when important business process changes and new transactions show up unannounced.
In a build-not-buy environment, asking for a code review may just save your bacon. You’d never build a house without stopping by to see how it’s going.
I’ll go one step further. We’d recommend a code review for all purchased software too. The same questions need to be answered before you sign up:
- How will the architecture of this solution support our changing enterprise?
- How sound is the foundation?
- What kinds of changes are easy to make?
- Where can we bolt on and integrate to our own secret sauce solutions?
COTS vendors will resist. That should tell you something.