From time to time, someone in the agile community mentions “The Agile Engineering Practices.” In most cases, it’s an article where the author condemns those practices while naming some of the reasons why they’re “considered harmful”. After the publication, the next thing to come is someone commenting about how the last article was totally untrue or that the previous author didn’t have a slightest clue about what “Engineering Practices” are anyway. I thought I’d come up with a neat cheat sheet to elucidate some of the mysterious terms involved in this discussion.
Firstly, just let me say one thing right of the bat: There’s something wrong with naming these practices “Engineering”.
Everyday we discover that creating software is really a craft, not an engineering endeavor, so we must change our nomenclature accordingly. If you want to check out what do we mean when saying that agile is more about “craft”, just read the Manifesto for Software Craftsmanship. The discipline is still important but the modern software development process is something more than “just” engineering. For that reason, we delineate the most useful, but not broadly understood terms you may find useful while working on your own projects:
Pair Programming – Collaborative Work
In the software development world it’s hard to find a method more annoying and potentially nerve-wracking than pair programming. “Programmers are not the kind of people that would work hand in hand with someone else – it’s unfair!” While it’s true that you cannot make people work together against their will, you can still survive few hours a day with a fellow programmer at your side.
Test Driven Design – Generating a plausible hypothesis.
Instead of bantering about how TDD may be good or bad, let’s try to understand what it actually means. First, it’s about creating a test to ensure that the code you’re going to write will work fine after the job’s done. Second, it’s about getting the design and architecture right, so that you’ll know what the test is all about and understand the framework you should follow to make the design last.
Automated Acceptance Testing – Meeting the client’s expectations
In the software development market, you may find lots of quaint terms for this one: Acceptance Test Driven Development, Behavior Driven Development, etc. There’s a lot of confusion about those terms but the main thing is to specifically describe what purpose should the software serve, and after that, automate the verification so all conditions described by client are being met on time.
Refactoring – Taking care of the mess
As we all know, the programming part doesn’t come out perfectly the very first time. Fortunately, most of the mistakes are intercepted by the unit tests. Oftentimes, everything seem to look fine after the first try, but after looking at it a little bit closer, we realize that there was much room for improvement. In other cases, it’s just the desire to make small adjustments when the design starts to emerge.
So, there it is – a quick reference for the most misunderstood terms in “agile engineering”. The reason for creating it was to get rid of some of the worries and minor annoyances we encounter in the tough software development market.