CULTURE & LIFESTYLE

It seems like everything is happening online these days. Thinking about going back and getting that degree? You can do it all online now! Looking to change jobs or searching for career advice? The Internet is your friend! Want people to stop telling you to go to school and get a job? Hey, no judgment here. Maybe you just need someone to tell you when to use Instagram instead of Snapchat or why your phone came with 117 different messaging apps or what the difference is between FaceTube and YouSpace. We can help with that too! Although you could probably learn that in school and then get a job and move out of the basement, but whatever…

Development Styles

by | Apr 26, 2019

Dear PropellerHeads: I manage a small IT group at work and some of my employees are trying to sell me on “agile development.”  It sounds interesting, but also pretty risky.  Does it really work?

A: It was smart of your employees to use the term “agile development” instead of “extreme programming,” which conjures up images of tattooed snowboarder-types staring wild-eyed at monitors and smashing cans of Red Bull against their foreheads.  “XP,” as the kids call it these days, is one of several software development techniques considered “agile.”

But there are others, and whether or not any particular one will work for you depends on several factors.  Applied correctly, by the right people and in the right environment, agile development can greatly increase the quality of your software projects.

So what, exactly, is it?  The details are spelled out at agilemanifesto.org, but the general gist is that a “lightweight” approach to writing code – one that is flexible and plans for changes upfront – results in better software. While the original manifesto site is cute, the agilealliance.org site is going to be a better resource for you to learn and transition to agile development practices.

The classic or “heavyweight” development approach focuses on upfront design and burdensome documentation. This leaves little room for customers to make changes or for programmers to make design improvements once the project begins.

A good analogy here is imagine you’re a customer and you need to make a change to the software you’ve asked to be made for you and it was only just discovered as you were testing the product. Now imagine yourself being a salmon that has to swim upstream to spawn. The challenge in front of you and the salmon are pretty much the same. Any guess how many salmon can swim up a waterfall? Surprisingly few, it turns out.

The “agile” part comes partly from emphasizing people over processes.  Programmers work directly with customers throughout the life of the project, delivering incremental but frequent improvements.  No more hiding in a cubicle for months before presenting a product and hoping for a good reaction.

Complications arise when teams are too large or are spread across the country, or these days, the world. There are benefits to increasing communication, even if it’s not face-to-face.  This might sound like common sense, but it’s still not the way many IT shops do things today.

Other aspects of agile development will sound scary because they’re different from legacy techniques.  I recommend implementing a few of the safer ideas and adding more intense techniques later if the first ones prove effective.

Extreme programming (extremeprogramming.org) might be the most well-known flavor of agile development.  Other examples include Scrum (scrum.org), Adaptive Software Development (ASD, adaptivesoftwaredevelopment.wikidot.com), and Feature Driven Development (FDD, agilemodeling.com/essays/fdd.htm).

Give one a try and the multiply-pierced, weekend base jumpers on your team can stop putting in 60-hour weeks and start training for the X Games.  You’re likely to find that your customers will be happier too.