Always Get Better

Posts Tagged ‘planning’

The Traditional “Waterfall” Software Development Lifecycle

Sunday, July 12th, 2009

You can still see ghosts of the traditional “waterfall” method of software development in modern agile practices. The traditional model involved long periods of planning followed by development and extended maintenance periods – ideal for long-lived systems (I’m shuddering and thinking of COBOL apps running on mainframes).

With today’s rapidly-evolving platforms and business’ intolerance for risk, developers are called upon to deliver solutions faster on changing hardware and software. The focus has shifted toward quick development cycles and constant integration.

At the basic level, the process is the same: plan, build, deploy.

A full understanding of the traditional “waterfall” software development lifecycle (SDLC) can help any programming communicate more clearly with project managers or clients who are more inclined to understand projects in these terms.

Phase 1: Planning (Logic)

The planning phase of the SDLC involves communicating with the project’s key stakeholders in order to understand the project’s requirements. What are the goals of the project, and what are the expected costs?

At this stage there is no program code involved, nor is there discussion of any particular programming language or framework. The goal is to understand what the new software will do and why; not how.

The planning phase is also the time to assess other possible solutions that could meet the client’s recommendation. This is where most analysts fail – rather than let their project stop at this point, many organizations will endeavour to push their own solution. Try to ignore the dollar signs – if you can meet your clients needs by integrating an existing solution rather than developing something new, you will make them happier because they save money and end up with a product that is completely within their best interests.

Phase 2: Design

The design phase brings us closer to writing code, but we still haven’t opened our IDE yet. At this stage our job is to create the software on paper based upon the requirements we came up with in the previous step.

Many clients feel like they are in over their head when your design starts taking form, but you can’t let them off the hook. You need to take the time to explain your design and make sure the client is fully aware and in agreement with what you are doing. Teach them how to communicate with you; learn the terms they use so you can speak their language.

Phase 3: Implementation

When we start programming, this is the part we envisioned ourselves doing. In reality, this is the part we do the least (assuming we did our job right in phases 1 and 2). We’re talking about getting down and dirt with raw code.

Phase 4: Maintenance

This is the most expensive part of the project – keeping the software running. If you’re lucky you will be gone after phase 3 – if your successor (the maintenance programmer) is lucky you will have done a thorough job of your documentation in all of the previous phases.

Maintenance deserves special thought because it occurs over time, so it gets absorbed as an ongoing cost to the business. It can be hard to justify spending a lot up-front to develop a new system when the existing one “already works, and costs less”. Always weigh the ongoing costs of developing and supporting features for an aging system versus performance gains and optimizations possible with new software.

Sometimes it makes sense to keep existing software in operation; sometimes businesses hold onto decaying systems far too long. There will always be a point where the newer system costs more to operate than the old would have cost for the same stretch of time; however, the total cost of ownership – satisfaction, new features, bug fixes – needs to be considered, not just the cost of implementing the new system.

People Cost More Than Equipment

Tuesday, December 30th, 2008

Much of the professional world has switched over to a two-monitor setup. I can’t even begin to imagine how I ever did with just one since I am now so used to having a help or a search open just outside of my main viewing area. Having reference material in my peripheral vision but accessible just by turning my head is much faster and less disruptive than having the fumble around the task bar and switch the focus of my attention.

It is said that switching tasks takes time – some users report productivity reductions of up to 15 minutes each time they have to change their focus of attention. If a programmer has to look at the documentation only once per day, their employer is looking at 1.25 hours of lost productivity every week, which may not seem like much but when extrapolated to that person’s yearly wage (averaging at $78k) the cost of the lost productivity is worth approximately $2400; much cheaper to buy that $500 monitor. For the general programmer, you can get by with less – a 17-inch LCD retails for less than $200. Sounds like a no-brainer, right?

The same logic can be applied to the purchase of an entire system. What is the productivity cost of having to wait for downloads and load times over the cost of a new system? Even if no new revenue is generated by the company directly as a result of the software or hardware purchase it can be worthwhile to invest in new equipment. Why hire someone and not provide them with the best tools possible to do their job? It’s kind of like putting a Mazda engine inside a Ford (wait a minute…)

  • improved satisifaction
  • reduced ‘switching’ time
  • employees more knowledgable with ‘current/cutting edge’ software

There was a time in the early industrial revolution when buying equipment and machinery was prohibitively expensive, and people could be trained to keep old hardware running for many years in order to maximize that equipment’s value to the company.

Today the reverse is true – computer hardware can be acquired at a fraction of a cost of the person needed to run it – and the training involved in having someone fill the shoes of a departed worker can be crippling to the bottom line of a business. Instead of trying to make machines last as long as possible it should be the priority of any manager to make the people last as long as possible. In a world where individual jobs are replaceable and just a stepping stone to “something better”, volumes are said by the simple act of someone staying in their role for a prolonged amount of time – both about the worker and about the quality of the employer they give their time for.