Home > Agile > The Agile Principles that impressed me most as a Software Developer

The Agile Principles that impressed me most as a Software Developer

April 27, 2011 | Jacob Stucky

The Agile Principles that impressed me most as a Software Developer

I spent the first several years of my career as a software developer in a non-agile environment. We didn’t purposefully follow any particular software design model, but we ended up getting fairly close to a waterfall approach. We would go through the motions of creating both requirements and design documents, but each phase would never seem to truly finish as we were forced to start later phases early due to time and budget constraints.

Without a clear development model, a developer might end up taking the mostly finished requirements document, a half-finished design document, and the memory of a conversation on how the system was supposed to work and spend a few months in development. The developer could easily spend months lost in the code without the support of another set of eyes to look at the code and assist with problems, or to keep him honest (i.e. not taking shortcuts, writing quality code).

Of course, developers always have deadlines, and in my experience in non-agile environments, it’s no surprise to have to put in long hours in order to meet the deadline and get the software released into a test environment. This was often the first time someone other than the developer would see the project; the extent of the testing being when the developer ‘tried it’ as a part of building the feature.

Hours of phone conferences, bug lists that are dozens of items long, and more months of hot fixes and changes would follow, and might continue well after the production installation. You hope to avoid, but are not surprised by arguments over budget, timeline, and what features were or were not included in the ‘approved’ requirements and design documents.

The result of projects such as these is that a single developer ends up ‘owning’ each project or large feature. If that developer ever leaves the company, there is a mad scramble to do a knowledge transfer to another developer for maintenance or new features. Heaven forbid the elusive ‘version 2’ ever gets approved and the new developer actually needs to have a full understanding of the system or feature.

When I joined Thycotic I was introduced to several agile principles. Here are the ones that made the most impact on me as a developer:

Test driven development

Test Driven Development, or TDD, was probably the largest and most difficult adjustment I had to make. This was not because I was ideologically against the goals or ideas of TDD, but because it requires an adjustment of how the developer thinks. For the eight years I had been writing software I’d always had a full plan in mind of how each piece of functionality would be implemented and would often stub out, or even fully write, methods that I would later need.

With TDD you do not work ahead in that way. You start with a single failing test and only write the code that is necessary for that test to pass. This is followed by another failing test, and the pattern continues, with a step to look for refactoring opportunities whenever you have full green tests. This refactoring is safe because you can simply rerun your test to confirm the code still works. The benefit of this process is threefold. One, you have not wasted time writing code that is not needed. Two, every bit of code is written in order to fix a failing test, giving you full test coverage and confidence that if the code breaks at any point, your tests will be able to inform you. Three, with properly named tests, by the time the feature is complete your tests serve as full code documentation for how the feature works and what results should be expected.

Pair Programming

Surprisingly, at least for me, the transition to programming with a pair was not a difficult adjustment at all. Even in my previous jobs there were times when someone was stuck working on a particularly difficult section of logic, and having two people look at the problem together helped solve the problem in much less time. Pair Programming gives you that benefit at all times. Not only does having a second developer working with you help when solving a complex issue, you and your pair also work together to keep the other focused. A pair working together is also more likely to follow best programming standards than an individual working alone due to the presence of peer accountability.

The Sprint

Working with smaller, manageable increments of time and a solidly defined amount of work is simply amazing. There really isn’t much more I can say about it. Instead of looking at a daunting project that will take months to finish, with no tangible goals in sight, everything is broken down into two-week increments.

The progress is tracked daily and it is easy to see with a glance how you are doing. There is rarely an impending sense of ‘This is never going to get done’ because you discuss and agree to what you can finish in the two week period. Everything else is outside the scope of the sprint, and thus outside the scope of concern for the time being. Of course, you revisit that additional work in the next planning meeting, but when you sit down to actually program, it is not hanging over your heads.

The sprint planning process is the most difficult part of a sprint because it means making sure that you can finish what you committed to, while at the same time not under committing. However, as teams gain experience, the process improves and as a result, so does the ability to plan accurately.

Verifies and QA process

For all but the simplest story there is a set of written “verifies.” For example, “Verify that there is an edit button on the page.” These verifies serve as a checklist for the QA process. The story isn’t considered complete until the entire list of verifies for that story are tested with a release build and signed off by the pair that performed the QA. Because of this guided and focused QA testing we have much more confidence in every story we complete, rather than if we had simply ‘tried it’ while developing, or after a fresh install did some ‘clicking around.’

Conclusion

I feel like I really hit the ground running at Thycotic. The agile techniques meshed well with my programming goals, and I immediately saw the benefit in this programming style. Moving entire teams to this style of programming would likely take effort, since it is a change in how programmers, management and clients interact, and it requires serious dedication from both programmers and all levels of management. But through this focus, I have also seen the benefit of more consistent results, better accountability, and a better quality product.

Jacob Stucky is a Senior .NET developer at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.

Categories: Agile
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: