Oct

10

Creating that masterpiece web site has often led me down a road of programming slop, as has most likely happened to many other developers out there. We dream up this revolutionary site that will be the best thing since toilette paper, only finding ourselves later struggling to solve unexpected problems while deadlines watch us like vultures. What started out to be a relatively easy development task based on our skill sets turns into a monster that eats up not only our patience and energy, but often times our income, as well. How can we manage to bring a project in on-time, on-budget, and in scope? It can be achieved through a cyclical process of estimation, design, review, revision.

The situation above is one that both experienced and novice developers often find themselves in. The sad fact is, this is probably the norm than the exception. What is more interesting is that most places, especially smaller organizations, believe that by leaving one or more of the steps out of the development process, the end product is going to be delivered sooner and at a lower cost. In every instance that this happens, though, the opposite is true. Inevitably the project is going to run into an “unforeseen” situation, which in turn has the potential to deal release. And every day that the project is delayed means that much more expense for the project is being accrued. Stopping this begins with the estimation phase.

In estimation there is something known as a “cone of uncertainty.” This is a fancy way of explaining how our estimation becomes more accurate the further into a project we get. When someone wants us to develop something, often times we are asked, “So how long is it going to take?” How many times have you answered, “Between 10 minutes and 10 month.” Since we have very little detail to go from, it is impossible to predict the total project life cycle. We need more information. As we acquire this information, we are able to narrow our estimation down. Here, however, is where the first mistake is made – we provide an estimate based upon our BEST case scenario. Oops, we have already set ourselves up for failure. Sure, you want to get the project or look good, but you are going to look even worse if you cannot uphold your end of the deal. And as soon as you start cutting corners, the game is over. The second mistake that is often made at this juncture is that we do not actually have a clear understanding of what we are developing. We THINK we do, but in reality we do not. This is where the design phase comes in.

Hopefully when I say “design phase” you are not thinking of Photoshop, slicing and dicing. Actually, I am referring to the creation of a Unified Modeling Language, or UML, document. This seemingly non-important document could potentially be your lifesaver. In modeling out your planned design, it forces you to think through almost every aspect involved in its creation. This means that things which could have been a potentially time-consuming problem can be caught before development ever begins. You can learn more about UML <a href=”http://www.uml.org/” target=”_blank”>here</a>. A UML document is very much akin to an architect’s blueprint. Essentially, they are. If an architect went to a contractor and said, “I have a building that I want you to build. I have it all planned out right here in my head,” the contractor would just walk away. As a developer it should be no different. We need to have our blueprints in-hand before we even write the first line of code. But the UML, just like a building’s blueprint, is not absolute. There are often times when we discover that while planned with every conceivable possibility, there is still room for improvement. This is why we need to review.

Reviewing is an in-depth analysis of the UML. This process is usually best accomplished when the proposed solution can be vetted within a group of developers. We can come up with what we perceive as the best solution to a problem, but reality proves that a team is far stronger than an individual. The point of a review is to make sure that every aspect of the design has been thought through, and that any potential gotchyas are caught before any code is written. Just like having someone proofread our important papers, we need those additional eyes and minds to bring to surface that one piece that we missed. And once we have reviewed the design, it is time to revise the estimate.

After the design and review phase, our understanding of the overall length of development time has dramatically improved, thus shrinking our cone of uncertainty. Since the estimate is integral to not just the client’s understanding of project milestones, but also for internal scheduling and planning, it is self-evident for the need to update the estimate. By providing a more realistic understanding of project’s life-cycle, we can more accurately set our target deadlines, helping to meet our initial goals. This, however, is not the conclusion of the process. As the project is developed, this cycle is repeated many times over, thus we always maintain absolute awareness of where our project, and ultimately our code, is heading.

So what does any of this have to do with object-oriented programming, or OOP? Everything. The underlying concept that we strive for in OOP is reusability and portability. By generating a road map through UML, we have the overarching view of how our final application might look like. This provides ample opportunity to determine where and when we can encapsulate, compose, inherit, and implement a more efficient design. With proper analysis, you should also be able to even gauge the scalability of the final application as well.

In the end, anyone can manage a project, but whether they are successful or not depends on their understanding of sound estimation and design principles. Take the initial time at the beginning to establish a solid understanding of your application, because that week or two of additional work could save you a month or more in the end.


Blogroll