Why Rapid Application Development is the Answer

Rapid Application Development (RAD) is described by Wikipedia as:

…a type of software development methodology that uses minimal planning in favor of rapid prototyping. The “planning” of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

RAD has given us the concept of prototyping via simple scaffolding methods that sit on a database and immediately give us a simple way to create, read, update, and delete (CRUD) records from the database. By making simple modifications to the code and writing custom queries against the database, you can get dynamic views of the underlying data so business units can immediately understand what they’re looking at and build custom reports without much hassle.

Enterprise-Level Development is (mostly) Dead

I postulate that enterprise-level development is obsolete for up to 70% of the projects that business units request through project management (another potentially wasteful unit… but more on that later). Most business units want simple tools that give them easy access to data and the ability to change the parameters on the fly. Sales and Marketing units want dynamically-generated graphical representations of the data to provide to customers, Operations units want productivity data and charts, and Intelligence units want raw data formatted in a way that they can apply statistical and economic models to them. The real kicker in today’s fast-paced economic world? The project details are always changing. How do you address these concerns with a long development cycle, constant quality assurance cycles, wasting time writing unit and integration tests, and slaving yourself (and your Technology department) to a single language for the sake of “continuity?”

You can’t.

A major business in Seattle that I’ve done some contract work for has this very problem – they’re an Internet company that has rapidly changing demands and requests and can’t wait for this giant cog (development) to turn to meet their needs. The Technology department works in a huge amalgamation of Java, Spring, Hibernate, and a theoretically agile and rapid framework of Groovy and Grails. However, the Groovy/Grails project is so out of date (running Grails 1.0.x) that it doesn’t integrate well with Maven and the major backend programming, so it needs to use Apache Ant. The result? A giant mess of code that is hardly agile. Business analysts in other departments get disgusted with the low usability of their tools and the slow development cycle, so they pick up a book or two and start developing their own applications using RAD concepts and frameworks (in this case, CodeIgniter). And guess what? They get more done than the Technology department.

A great RAD framework.

Talk about a shattered workplace!

I empathize with those “rogue” business units, because they’re the ones that have it right. Too often I see Technology departments who are simply out of touch – they rely on Project Management to buffer them from the businesses’ requests and complaints, and don’t ever get involved with the people who need the changes. All they see are tickets for sustainment upgrades and requests and say “Prioritize this for me,” never spending 5 minutes with an employee who is actually affected by the problem! They have no understanding or empathy for the people they serve, and they get out of touch with the business as a whole. They lose track of the cardinal rule of Technology:

Technology serves business units, NOT the other way around!

Tech departments develop applications, tools, and database changes so the business units can make money. DO NOT LOSE SIGHT OF THIS CONCEPT!

So, What’s the Answer?

Enterprise-level development is very useful for “large cogs” that need to move slowly – packages like business logic, data models, and major back end work should be subject to strict unit and integration tests and require a lot of quality assurance to make sure the project has a solid foundation. Developers who specialize in this kind of work should absolutely be kept on and focused on this type of work – making developers constantly change from project to project and from an enterprise-level development mind to a rapid development mind will lead to very low productivity and a lot of grief. Technology departments need two sets of developers – an enterprise-level team that has project managers to lay out all the major changes and requests, and a rapid development team that has little to no project management. The rapid development team needs to be staffed with developers who have extensive experience with working with business units – ideal candidates are analysts from business units who studied computer science in college and have a few years of programming and database experience.

Enterprise-level teams are assigned projects that relate to major logic/database changes and back end processing while the rapid development teams get smaller and medium projects that take the existing logic and database and transform it into dynamic reports, automatic alerts via email/SMS, and better and quicker access to the data they need to get the job done.

Sound familiar? This is the popular computer science concept “Separation of Concerns” applied to a Technology department! Let the enterprise “layer” work on complex projects while the rapid “layer” picks the low-hanging fruit and immediately improves productivity of the business units!

Rapid Application Development – Outside of the Regular QA Process

Assuming the Technology department is split into enterprise and rapid development teams, how do you test the rapid development team’s work? By subjecting it to the same QA processes that the enterprise-level team does? Absolutely not. Since the requests from the business units are constantly changing, the rapid development team acquiesces to these demands but also pushes demands of their own – that the business units must carry some of the load of QA! Rapid development teams will perform their own QA on the simple tools through best practices (a simple list of data validation methods for forms, navigation tests, etc) to catch the major problems, but business units will have to do further refinement through a User Acceptance Testing cycle. This cuts down on payroll and helps get the business units involved in the process, making their contributions feel important and ultimately helps to deliver a better product through collaboration!

Conclusion

Here’s the simple cliffs notes:

  1. Enterprise-level development is inappropriate for most of today’s business concerns, especially if the business in question is a fast-paced Internet company.
  2. Rapid application development (RAD) is the answer to quick productivity requests.
  3. Separating the enterprise-level teams from the rapid development teams increases the productivity of both.
  4. Getting business units involved in User Acceptance Testing early in the process increases morale and the quality of the final product!

I hope these concepts make sense and can be implemented at your company – it’s a surefire way to improve productivity!

Leave a Reply

Your email address will not be published. Required fields are marked *