Agile or waterfall

Coke or Pepsi? Miller or Bud? Mac or PC? Agile or Waterfall?

When a consulting company embarks on a project, what is a better methodology to use: Agile or the traditional Waterfall? What projects lend themselves better to one or the other?

Waterfall methodology seems to work better when a project presents a known problem with a known solution. Upgrading a server, creating a time-off system, or building a submarine — all are projects that are better executed by the waterfall approach. You know the problem, you know how to solve it, chances are you’ve solved it before and probably more than once. Each project will have a defined scope, a set of requirements that must be met in order for the project to be completed: the server must be upgraded to the new version, the time off system must allow employees submit leave requests, and the submarine, well, the submarine, must submerge. There’s little room for creativity, in fact, creativity may be bad — a creative approach may cause the submarine to sink or the leave request to violate HR policies.

Unexpected problems may certainly arise in each project, but nothing that would require you to completely change your approach. Nothing that a good PM can’t deal with.

The Agile methodology, on the other hand, seems to be better suited to that creative approach. You know the problem, but you don’t know how to solve it. Building a system to allow employees take advantage of a new benefit and trade unused time off for cash or for cash donations to charity may be an example of such project, especially when the HR policy around this benefit is still being defined. Such project would not have a defined scope or a set of requirements. The requirements are going to be defined throughout the project as it is being built and features are starting to take shape, sparking new ideas and new features.

But there’s a caveat. The business owner, the client needs to know what they are getting into it and agree that their project is going to be an Agile project, a creative process focused on delivering business value rather than fulfilling a set of requirements from a contract.


Consumerism era in software – they don’t make them like they used to

“They don’t make them like they used to”. This phrase is normally applied to physical things: cars, houses, kitchen appliances, men. All of those things (well, perhaps, except for men: that’s a topic all of its own.) fell victims of the ever growing and demanding consumerism of our society. The average ownership expectancy of many items is as long as the corresponding loan or the development cycle of a new model. As soon as we’re done paying for our car, we’re running to the showroom to trade it in for something new. We upgrade our electronics as soon as the new model has enough new gimmicks to appeal to us or as soon as our neighbor gets a bigger model. We change our phones as soon as the 2-year contract runs out. (Admittedly, the recent economic downturn forced some people to change their behavior, but it will certainly come back as things improve once again.) And if we don’t expect to own an item forever, we certainly don’t expect it to last forever and we don’t want to pay for that kind of robust engineering. We gladly trade longevity for features, for the proverbial bells and whistles.

Enter the last frontier — the world of custom software, IT systems and websites. They don’t build them like they used but nobody wants to invest in the old ways of building software.

We, the consultants and the systems analysts, used to pride ourselves on building well-architected, robust, enterprise-ready, scalable, easily maintainable systems that would be able to grow and adjust as the organization grew and its business needs and processes were changing. Those systems were all soft-coded and driven by reference tables and rules. Once the application was completed, business users would take ownership of it. They were able to change keyword values, modify workflow rules and change approvers on the fly — all without involving the developers. Those systems were expensive to build and often took a long time to be tested and deployed. But they also lasted 10 years or more.

Today, the average life expectancy of a system averages about 3 years. This trend is very prevalent in consumer software and is now showing up more and more in the enterprise arena. It takes 3 years for an application to go live, to be used to death and to hit the wall where it can no longer support the growing needs of a business. It then either gets abandoned or, more often, rebuilt and migrated to a different platform.

The overall mentality and approach towards custom IT systems is changing. If I don’t expect a system to last, I don’t want to invest in the whole design and architecture phase of the project. I have a business problem to solve and I want it solved fast and cheap. And if for the next 3 years I need to periodically hire a low-cost contractor to maintain or slightly modify the application, so be it. It still works out cheaper than building a soft-coded rules-driven application.

These systems are expandable and the skills involved in building them are quickly becoming commoditized. No longer are the decision makers willing to hire Michelangelo to spend 4 years to paint the Sistine Chapel. They are more interested in a graffiti artist who can do it overnight. The Renaissance of software development is over. Get used to mass production and consumerism. The question is how do you survive and compete in this era?

The other day I picked up my college Systems Analysis and Design textbook. That book taught us how to be Michelangelos of systems design. Whole sections were devoted to interviewing decision makers and observing their behavior to understand what about the new system is truly important to them. That takes weeks of time. Weeks, which these decision makers don’t want to pay for.

To me, there are 2 rules to be successful under this new thought process:

  1. Accept trade-offs. Not every application you write is going to be a monument to best practices of software design and architecture. It is OK not to modularize everything. It is OK to hardcode some things. If your customer wants to pay for a Chevrolet, it is OK to give them a Chevrolet. Not every solution has to be a Cadillac.
  2. Don’t get attached. Not every application you write is going to be used by 50,000 users world-wide for the next 10 years. Some will be used by 100 people for a couple of years and then get replaced with something else. Accept it, deal with it and move on.

These work for me. How about you?

How was your weekend?

When someone asks you that question, how do you respond?

How was your weekend?

What did you do this weekend?

Almost everyone chooses one of the standard responses: “It was OK”, “It was good” or “Nothing much”.  And then they leave it at that.

Most people though, when they ask about your weekend, they don’t really care about YOUR weekend, per say.  What they really want is to tell you about theirs.

So next time someone asks you about your weekend try to end your reply with “And how about you?”.  You may be surprised as the person opens up with some amazing story about their weekend.  Whether a big gathering of friends, someone’s getting married, a kid getting a driver’s license — they most definitely have a story to tell.

With a little practice you’ll get good at it.  And then try to apply it to other questions, too.

It’s great to work with a great team

Every now and then a project comes along to remind me of how great of a team I have the privilege to work with at PSC.

Our client had asked us to come up with a custom solution to secure large PDF files.  They have a DRM solution, LockLizard, but, considering the large number of users involved, didn’t think it was appropriate in this case.  So, in about 1 day, two of our “Notes” consultants came up with what the client called “one of the most elegant solutions” they have ever seen.  Even though it was designed by our Notes team, the final solution does not involve Notes but rather a custom application to secure and package the PDFs.

If all you have is Lotus Notes, everything looks like an NSF.  But in today’s world, it is impossible to stick with one tool, with one solution.  A great consultant is not afraid to stretch out of his comfort zone and admit that his tool of choice may not be the best tool for the job.  If Notes doesn’t fit, don’t try to shove a square peg into an NSF.

I am glad that at PSC we have great consultants.

There’s always someone better than you

The other day, cruising down the I-290 at about my usual speed of somewhere around 80 miles/hour, I was suddenly overtaken by a Cadillac Escalade. The Escalade passed me like I was standing still, I don’t even want to guess how fast he was going.

Up until the moment when the Escalade passed me I was passing everyone else around and feeling pretty good about it. But, no matter how fast or how good you think you are, there’s always someone better than you. You may be the fastest car on the road or the best developer in the community– but that only lasts for a while. It is only a matter of time before someone passes you or someone starts slinging code better than you. Moreover, in today’s flat world economy, there are plenty of people who are not as good as you but they are a whole lot cheaper.

So as the world-wide economy is tanking, as companies are looking to cut costs to stay afloat, as unemployment is inching up and various indexes are sliding down, how do you ensure that you yourself stay competitive in the job market? How do you differentiate yourself? How do you ensure that you remain a billable and employable consultant or a technical resource? How do you avoid being replaced by a code-slinging body shop 10 thousand miles away?

Do you learn new languages? Do you learn new platforms? Do you pick up business or project management skills?

Or do you close your eyes and hope that none of this applies to you?