Agilification

How do you know if you are an agile software developer?  How do you know if your team is agile?  It is easy to say you are.  It is easy to intend to be.  It is easy to lose agility if not continually maintained.  On long projects focus shifts often.  Success is a moving target.  Agile practices have to be retuned and reapplied periodically.  That’s how it was intended to work.  That’s what makes it beautiful.  It’s a solution to be implemented later.  

The Agile Manifesto is a guideline for writing better software.  You could say it is a loosely coupled collection of best practices.  The Agile Manifesto does not contain a significant amount of detail and I believe that’s intentional.  It’s composed of a dozen flexible recommendations.  It’s not a script or a rigid doctrine of rules.  There is room for interpretation.  This freedom allows for easy adoption.   It also allows for radical variations.  Care should be taken not to let freedom become an evil mutation of agile practices.  If in doubt or debate, remember, “Working software is the primary measure of progress.”

It’s easy for teams to allow existing bad habits to remain when moving towards a more agile environment.  Understandably, old habits die hard.  Agile teams should actively identify their bad habits and discuss ways to eliminate them.  Allowing bad habits to evolve and masquerade as an agile practice is an evil mutation.  To avoid this, a team should continually improve their process.  Review the Twelve Principles of Agile Software as a team.  Eliminate rigid and strict processes.  Remove unnecessary steps in processes.  Find new ways to improve efficiency.  In short, tailor your process to best serve the team and your users.  Determining how best to implement the Agile Manifesto is up to you.

The Agile Manifesto has a lot to offer software developers.  Being agile in your profession is not limited to the software industry.  Many teams can learn lessons from the guidelines put forth.  Just as the software industry gained inspiration from a patterns book written on architecture.  The Agile Manifesto makes good sense in the work place.  So, if you strive to be agile, you should ask yourself often; self, are you agile?

Tags: agile

The title of this entry is a standard mantra for agile programming efforts.  And sometimes agile principles apply in other arenas besides software development.  For example, my wife and I came up with a great idea for carving pumpkins this Halloween.  In years past, I carved pumpkins like just about everyone else: with a large, foreboding knife that awakens fearful images of horrific scenes when wielded.  Well no more, because sometimes the quickest thing that works is also the safest thing.

First, set the butcher's machete aside.  Now trace a face on the pumpkin with a pencil.  Next, grab a drill (cordless is handy, though any drill will do).  Yes, I said a drill.  Now make holes in the pumpkin using the drill, following the outline you drew with the pencil.  The end result looks really cool and was much easier than using a knife.

So, I guess the lesson is that sometimes an unconventional approach pays off.  If you try drilling your pumpkins this year, let me know how it goes.

Tags:

Debates around inversion of control containers (IoC) have a tendency to turn for the worst very quickly.  While there are common goals of loose coupling, improved testability and greater cohesion, often it seems that a lot of effort is spent debating about choices regarding which IoC container to use.  The debates grow especially intense when a framework is created with a dependency on a particular container.

A couple of months ago, Jeremy Miller suggested the creation of a common library so that developers could allow consumers of their frameworks to plug in the IoC container of their choice (It's time for IoC Container Detente).

After a few short weeks, the Common Service Locator project was born.  This project provides a simple adapter and static gateway for registering the IoC container of your choice into a framework that leverages the Common Service Locator.  I created a StructureMap Adapter for this project that you can download on CodePlex.  For simple, in-house applications over which you have complete control, there may not be a need for such an adaptation.  But there are times when swapping out different container implementations is useful, so it's nice to know that it's there when you need it.

Tags: ioc, s.o.l.i.d.

Before this year, I spent a lot of time learning and developing with CAB (the Component UI Application Block). This was a great opportunity to sharpen my skills for using good object oriented design princples (like favoring composition-over-inheritance and depending on abstractions, not details).  The trouble with CAB is that it is a heavyweight beast of a framework and it takes an average developer an inordinate amount of time to become productive when using it.  Fortunately, Microsoft listened to the community and decided to scrap CAB in favor of a new project called PRISM.

That's the good news.  The bad news is that in order to ship according to deadlines, the PRISM team was forced to complete their project without support for WinForms.  This wouldn't be so bad if Visual Studio 2008 had decent support for WPF (Windows Presentation Foundation), but currently the WPF designer support is severely lacking in Visual Studio.  Also, the learning curve for WPF is quite steep for most seasoned WinForms developers.

Brian Noyes to the rescue.  Last week, he posted some example code where he begins to port PRISM to WinForms.  Here's hoping his Composite Extensions for Windows Forms is just the beginning.

Thanks to Glenn Block for the heads-up!

[UPDATE] Just as I finished this post, James Kovacs posted some new PRISM related content. It seems like the buzz around PRISM is building steadily.

Tags: winforms, prism, cab, compositeui

The title of this post is not a command to readers but more of a request to myself.  I believe strongly in starting any project, any feature, with a simple approach.  Correction, the simplest approach.  I write code to satisfy requirements.  I know my first attempt is not the final solution.  I promise myself, with every line I write, I will improve this code when I have more time.  The time stipulation is the kiss of death.  Improving your code should be a personal priority.  Time constraints can be overcome with discipline.

Help Yourself, Help Your Team
Start your sprints with code, start your sprints with tests.  You cannot refactor code that does not exist.  Write code! It will probably be bad; even the gurus write bad code.  This is why alphas and betas are so prevalent in the industry.  No one gets it right the first time and if they did--we wouldn’t need refactoring or TDD.  Developers need to combat writers block like a traditional novelist (keep coding).  Strive for improvement, ask your team to review your code. It’s okay.

Experienced programmers should encourage their inexperienced counterparts to code.  Let them drive when pair programming.  Resist the urge to interrupt the linear learning process.  Programmers tend to be hard on themselves and even harder on their peers.  This is an extremely anti-agile practice.  Agile programmers succeed together and fail together.  That is the precious gem that makes ‘Agile’ more than just a buzz word.

Tags: agile, refactor

Last week, Derick Bailey presented at the Austin .NET User Group meeting.  He's posted his slides and sample code from the presentation and it's well worth the time to review.  Derick does a spectacular job laying out the specifics of SOLID object oriented design principles.

• S (Separation of Concerns)
  
• O (Open/Closed Principle)
  
• L (Liskov Substitution Principle)
  
• I (Interface Segregation Principle)
  
• D (Dependency Inversion Princple)
  

The power of Derick's approach is that he starts with a simple solution and then refactors to patterns, rather than simply showing off a completed application with heavy use of design patterns.  This is a good reminder that design patterns aren't a good thing in-and-of-themselves.  In fact, unneccesary use of patterns is a code smell--if all you need is a simple solution, then create a simple solution!  But as requirements change and become more complicated, it is vital to have the knowledge for how to modify your application to accomodate the necessary changes.  Derick's presentation will help you understand the principles and patterns that will enable you to face changing requirements with confidence.

Tags: s.o.l.i.d., ioc, oop

Agilification is dedicated to agile software development principles and team management practices.  To find out more, check out the Agile Manifesto and the Principles behind it, or subscribe our our RSS feed to get updates when new content is added to our site.

Tags: agile