eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Here you are—CEO of a big, successful corporation—and youve decided that now is the time to erect an office building befitting your success.
You bring in architects to design the new building, and, after some time, they present you with their plans. As youre looking at the building design, you immediately notice something strange: There are no doors or entry points of any kind on the ground level of the building, and the design concept the architects have chosen would make it very difficult to add them.
When you point this out to the architects, they dont apologize and redesign the project to provide ground-level entry. Instead, they smirk condescendingly and point out that they can create plenty of ways to get into the building, such as an outdoor staircase that provides access through windows on the 20th floor.
The exact scenario Ive just described would never happen in the real world. No architect would design such a building, and, if he or she did, no client would agree to a design without ground access and would demand that this be added.
But a similar scenario does take place every day, with software developers and vendors proposing coding solutions that are essentially the equivalent of a rickety outdoor staircase to the 20th floor.
The problem is that many IT executives dont know enough about code to realize when a wacky workaround is being used. All they know is that they asked for a certain capability, and the developer said, “No problem—the application will do that.”
To explain where developers are coming from, Ill use the building metaphor again. Imagine youre a builder. You come to a wall, and you realize you dont have the tools and supplies to put in a door. You realize that it will cost a lot of time and money to stop what youre doing and run out and buy the necessary equipment. So you build a complex system of pulleys, nets and lifts to get people over the wall. It works, but the solution is nowhere near as effective as a door.
The same thing happens in coding. You start a project with a certain set of tools and an initial set of design logic. But then someone asks you to add a feature that wasnt in the original specs. Rather than start from scratch—looking for just the right tool set to address the project including the newly requested feature—you do what you can with what you have.
IT executives often set up these kinds of situations themselves with poor initial design concepts and constant feature creep. Developers really dont have too many options if the project was poorly thought out to begin with and if someone keeps coming in and asking for new and often disruptive features.
But, no matter who is to blame, crazy and complex coding often leads to bugs, security holes and failed application deployments.
What can companies do to avoid this?
First, Id recommend that IT executives put in more time learning about the languages and development platforms used within their companies. IT executives seem to have the time lately to take business classes to get ahead. This is a good thing, but not if its at the expense of the core areas of these executives jobs.
IT execs dont have to become master coders, and they definitely dont want to go through development projects line by line. But they should know enough so that large and unusual changes jump out at them when they look at a project.
Also, IT executives should ask how developers plan to proceed with a project. This should quickly determine if the developers are taking an appropriately simple route or if theyre building the code equivalent of a Rube Goldberg contraption. Finally, IT executives should perform proper prototyping during the planning stage and avoid feature creep whenever possible.
Developers, meanwhile, should be honest and say upfront that a feature will be difficult to implement or that a redesign or new tools will be necessary for a projects success. Developers should also lay it on the line about the negative effects of late feature requests.
The goal of every major software project is success—however thats defined. With the right tools for the right job—and through open and ongoing communication—that goal can be achieved.
Labs Director Jim Rapoza can be reached at [email protected].
To read more Jim Rapoza, subscribe to eWEEK magazine.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.