Avoiding All-Too-Common App Development Pitfalls
Software development drives business innovation, but many application development teams are stymied by some common, solvable challenges that can sidetrack the success not only of their project, but also of their company.
The top three: achieving effective alignment with business concerns; managing time over the course of a project; and building for reuse.
1. The Alignment Gap
The first mistake app dev teams make is a golden oldie: failure to align the application development process with business requirements and expectations. You'd think we'd have the so-called alignment gap problem solved by now, because it's been talked about ad infinitum over several decades. Yet it remains one of the most common problems among development teams, specifically, and IT organizations in general.
An alignment gap leads to missed deadlines, loss of trust, and missed opportunities for the people who will be using the new software. There's no reason today -- with our understanding of requirements capture, quality control tools, and development methodologies -- that this issue can't be forever eliminated from this list.
2. Iterative Development
Nearly half of all enterprise application development projects miss deadlines during projects. Think about that number for a moment. What if half of all phone calls never went through? Or half of all newspapers were delivered a day late? Or half of all flights were delayed? That's an unacceptable statistic by any measure -- and yet, there it is.
There are many reasons why deadlines slip, but some are more common than others. One huge driver of deadline slippage is teams trying to do too much at once and ignoring the complexity of what they are developing. Rather than simplifying the requirements list to a manageable set of features that can be delivered in 30 days or less, teams tend to create monolithic features that take months or years to fully develop.
It is also typical for teams to "gold plate" new applications as they're being built. Developers add layer upon layer of bells and whistles they believe improve the software in some way.
Those features aren't in the original specs, they're not essential for the current build, and they burn cycles that otherwise should be devoted building, testing and debugging core functionality. They might be great ideas, but they should be tabled for a future build. The result: scope creep that slips deadlines.
3. Code Reinvention
Last up, another well-worn problem: the failure to build for reuse. We've seen literally billions invested over the past 30 years by researchers, vendors and educators to deliver
- object-oriented languages,
- component-based development,
- service-oriented architecture (SOA) and associated methodologies.
All of this was invented and evangelized with one purpose in mind: to help organizations build reusable code. The more code reuse in an organization, the more agile and cost-efficient their development can be (which, incidentally, helps eliminate the IT alignment gap).
Why build for reuse? Beyond the obvious benefit of faster time to market, apps built for reuse require less effort to port to new platforms; they're easier to extend or repair quickly; and they're more reliable, since a good portion of the app is powered by field-proven, robust components and services.
However, brittle, inflexible, big balls of mud still vex the enterprise today. Despite all the advances in languages, tools, and methodologies -- and despite the obvious benefits -- enterprise development teams often fail to architect for reuse to this day. Talk to any developer who just joined a team and is trying to leverage, integrate with, or just figure out existing code, and you'll see how bad the problem still is.
Make Quality Job One
Here's the sad part. All of these challenges can be easily addressed at the start of the application development lifecycle. There are well-worn industry best practices, software development methods, and application lifecycle tools that ensure developers hit their mark the first time, every time.
The first thing a development manager needs to do when embarking on a development project is to sit down with the business owner, and be certain a clear definition of the business requirements is captured. Once these needs are understood, the development team can move forward with an application prototype.
This provides a working model of the software that the business owner can review. Identify any required changes before full-blown development work kicks off. The prototype will also help the development manager work with the programmers to estimate time and resource requirements, and work up a cost estimate.
Next, before the devs make a mad dash to their workstations to begin coding (and gold plating) the application, someone with strong architectural skills should create a blueprint for the software. The architect should design the system in layers that address the various business and technical functions of the application. A skilled architect will create an n-tier, component-based, service-oriented architecture that breaks the application down into user interface, business logic and database layers.
This type of design will make it easier for the devs to work on their particular components. And once deployed, an n-tier architecture makes it easier for developers to apply updates by swapping only the components that need changing. Lastly, adopting a component-based, service-oriented approach encourages developers to build components, and define and document public interfaces in tandem, moving projects more quickly toward completion.
Once components and the services they provide are mapped out, the development manager should prioritize which application features need to be built first. That decision should be based on the return on investment the features are expected to deliver. Rank features based on what is:
- Must have (crucial to the application's operation or meeting documented business requirements)
- Useful to have, but only if time allows
- Nice to have, but only after core functionality (No. 1) is complete and time allows
- Good idea for later possible builds
Note that items 2, 3 and 4 are all gold plating. Aligning to the business objectives from day one helps close the IT alignment gap. Setting priorities helps keep the project on track, preventing scope creep. And defining components and services before a single line of code is cut lays the groundwork for higher ROI over time by preparing for reuse. In the end, the team has a much better chance to deliver an application that works as originally envisioned to the business on time.
There are proven practices and methodologies that promote these principles. Agile development processes divide the application development project into iterative processes carried out by collaborative teams of developers. Agile encourages fast development sprints and quick responses to changes. And it works. Experienced Agile teams can deliver projects once considered death marches in weeks, instead of months or years.
The goal of Agile is to allow developers to write and test code on a daily basis, while incorporating continuous process improvement into their work. Scrum is a popular project management framework that embraces the principles of Agile development. There are others. But despite the fact that Agile has a proven impact on code quality and team productivity, only about 35 percent of corporate IT departments use them.
Better Tools, Better Results
That's starting to change, as better tools for educating, implementing, and managing Agile teams and their projects become available, affordable and adopted. These tools are easy for development teams to learn and use. Once put into use, the speed of the development process accelerates, code quality improves, the alignment gap narrows, scope creep fades, and code reuse can go way, way up.
"Lifecycle management tools" is a principal tools category IT organizations turn to when they want to implement Agile and other industry best practices. These help any proficient development team create top-quality apps that meet requirements and are delivered on time and on budget. They encapsulate and enforce Agile development and testing methods that foster highly efficient development teams. The result: better up-front planning, fewer re-dos, less wasted effort, and reduced developer burnout.
By running a well-defined project, where the goals and requirements are clear, and teammates understand their roles, reliably delivering well-scoped applications can be a breeze -- and you and your team will be seen as strategic partners in the ongoing success of your company.