….On the Importance of Requirements Gathering

You just purchased an empty 5-acre lot on a serene, wooded lake in upstate New York. You’ve been saving up for your dream vacation home, and the time has finally come to look for someone to build it for you. You narrow your search down to two construction companies; let’s call them Moe’s Mansions and Bootstrap Home Builders.

The account manager from Moe’s tells you he can build you an amazingly beautiful house, one that will be designed as it is built so that he can be sure to satisfy your needs at every step of the way. Why waste time designing everything upfront when you can just dig in right away, get your hands dirty, and build it quickly and with utmost agility? He says you’ll begin by defining the size and shape of the living room, and once that’s built you will continue to add on rooms until eventually you have a whole house. This is the best way to do it, he says, because you may not know what all your needs will be in advance, and as you see the house take shape, your needs may change.

The account manager from Bootstrap tells you he too can build you an amazingly beautiful house, but unlike Moe’s, Bootstrap says they will lead you through a detailed discovery and design phase, one that will attempt to flesh out your needs before one speck of dirt is cleared for the foundation. Bootstrap will clearly document all your requirements, and their architects will then draw up expert plans that the builders will use to guide their process.

Well, faced with these two options, of course you’d choose Moe’s right? Why would you waste money paying for an upfront design phase when you could just get started today with the actual building? And yet, how many houses can you think of that have been built without plans, without detailed architecural designs drafted by a skilled professional trained to elicit your requirements and translate those into instructions the builders can follow? It would be absurd to build a house the Moe’s way.

You would end up with a patchwork quilt of a home, whose later additions better reflected your desires than the first rooms you built. And what happens when you find out in order to build a second floor, you need to completely redesign your first floor to support that? Or what happens when you find out well into the building process that building a patio is going to cost three times as much as you had expected, and will take five times as long? Or worse still, what happens when Moe says he doesn’t even know how to build that screened-in porch you’ve always wanted. Woops.

At Bootstrap Software, we architect solutions custom-suited to your business needs and goals. In our discovery and design process, which takes place before developers write even a single line of code, we work systematically with our clients to examine and document the rules, workflows and idiosynracies of their businesses. Many people balk at the idea of spending time and money upfront to archictect a solution up front, but when you’re building complex systems that may require numerous points of integration with other systems both internal and external, it is the only way to go. Otherwise you end up with Frankensoftware.

Agile programming (Moe’s way) does have a place if 1) for circumstantial reasons you cannot elicit the requirements until you have something up and running 2) you are willing to pay (in time and $) for a functioning prototype to be built that may have to be rebuilt or re-factored.  We also understand that requirements may shift once an app begins to take shape (like deciding a granite countertop will work better than formica once you have seen the feel of the kitchen).  We mitigate this through our clickable wireframe / prototyping we do as part of discovery and design.  So if you are asking if we are “waterfall” or “agile” let’s just say we take the best of both worlds, customized to the project’s specific needs and bake an SDLC cake that serves the project.

Jamie Forrest
Project Manager

Why Use a PHP Framework

Several problems can arise when applications contain a mixture of data access code, business logic code, and presentation code. Such applications are difficult to maintain, because interdependencies between all of the components cause strong ripple effects whenever a change is made anywhere. High coupling makes classes difficult or impossible to reuse because they depend on so many other classes. Adding new data views often requires re-implementing or cutting and pasting business logic code, which then requires maintenance in multiple places. Data access code suffers from the same problem, being cut and pasted among business logic methods.
The Model-View-Controller design pattern solves these problems by decoupling data access, business logic, and data presentation and user interaction.

MVC divides an application into three concerns:
• Model – Encapsulates core application data and methods for accessing it.
• View – obtains data from the model and presents it to the user.
• Controller – receives and translates input to requests on the model or the view.
The separation into three concerns is inspired by a information processing model where the controller represents system input, the model represents processing and the view represents the output of the system.

Pros

- Better Maintainability: Orders of magnitude in ease of maintainability.
- Code Faster: Separation of business logic allows for ease of reuse which in turn leads to faster development and less time on tedious maintenance tasks.
- Redesign UI Easily: Ability to reskin entire application very easily.
- Ease of growth: Controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained.
- Already in used in Enterprise sites such as Yahoo Bookmarks.
- Database Abstraction: Most frameworks can easily switch an entire application to use MySQL, Oracle, or SQL Server. Code is not database specific.

Cons
- Need to become familiar with specific framework

Leading Options

Michael Sleman
Tech Lead