Why Do We Care?

I am sure you are all familiar with it; every development group has at least one crazy yahoo who keeps shouting: clean code, more unit tests, continuous integration, decouple layers, quality, quality.... quality!! If you are such a person - Thank God and welcome to the club :-)

Why would anyone willingly take a role of Software Development Don Quixote? Let's try to analyze it.
First of all, what are we fighting for? Money! strangely - no. Promotion! again - no. We're fighting to get better dev tools, raise code quality, reduce bug cycles, reduce maintenance cost, reduce new features cost. Odd, but none of the above will give you any personal gain. The only ones gaining from this are our software product, our company and eventually - our clients.

Why do we do it? we do it because we care. Simple equation: when you write bad code - you don't care. We get paid for our work and we're trying to give it's worth in coding. When you justify your salary with skilled labor: you're not doing anything special - you're just doing your work.
For example, let's take a restaurant scenario: every time you go there you have to return your order several times because it's not properly made and when you examine the kitchen you see an old stove, dirty pots and pans. You wouldn't think the menu worth anything, right? Same goes with code, when you examine your tools, code quality and development cycle - is it worth your paycheck?

Why do we care? we care because we are pros! We take pride in our work and wish it to be as professional as possible. We strive to elevate quality around us, we are eager to learn more and we keep fighting those small code quality battles. We attend tech talks, meetups. We join forums, exchange technology ideas, form software groups (e.g. Software Craftsmanship) and try to set an example to other developers.

So, are we really that crazy for doing all of the above? No, we're professional developers.

Team Coding

Ever seen a class and started thinking the only way to understand what it does is by rewriting (or deleting everything). This feeling has really no basis but it's more of a feeling that something just doesn't seem right. The truth is that we all find it easier to read code written by us than by others. Despite that, there is highly readable code and less readable. There are thousands of articles on code readability, clean, structured (newspaper metaphor), craftsmanship and other terms describing characteristics for code writing. But what characterizes a professional programmer? Extensive knowledge? Ability to lead a technology project? Or rather the mere definition of his directors that that developer reliability is of fire and forget. I think that what characterizes a professional developer is the ability to share, understand, expand and modify their work by other members of the development team.

I would like to coin another term - team coding. The way I see it, programming for a readable and clean code base is far superior to maximum efficiency. Team usually conform to some standard or a way of writing code (usually, a complete mess). Since most developers will simply follow the same style they encounter (explained partially by the Broken Window Theory), the style shouldn't be left undefined. Defining coding standards along with formatting rules, coding style and even how to write issues and comments might ease the development process. Here's a real life example: In a recent lecture I presented my development group how a unit test is structured. I explained that mocked members should have the mock prefix (e.g. mockFoo) and usually the class under test is called tested (or classUnderTest). As times went by, unit tests were added to the code base (thank God!) and additional test cases were added to existing ones. I sat for pair programming with another developer. When we reached to the part of adding a new test case she immediately wrote a case without even looking at the the field deceleration, simply by following the coding conventions for tests. That's team coding! Another team member was able to continue another developer work without too much hassle.

Style rules and automatic formatting actions reduced merge scope to conflicting statements only and developers can focus on what to write instead of where should a bracket should go. Modern IDEs (I'm currently working with Spring Tool Suite - an Eclipse distribution by SpringSource) support save actions that can configured to apply shared style rules. Oracle publishes Java Coding Conventions that will suite most teams. In my development group we took them as a basis and changed it a bit to better fit our code structure. The process of setting coding standards was long and had it share of discontent but these guidelines (style, standards, best practices, etc.) made our code base look (and feel) much more organized.

Some might argue that we reached the days where coding standards are not needed. I even heard an argument that every programer codes differently, and setting such conventions will damage their individualism. To that I have only one thing to say: Software development is like Communism - either you work as a team for the good of the company or you're sent to work on some BS assignment cleaning code. If Communism is not your thing and you're more into French stuff the idea is the same as The Three Musketeers :-) 

Unit Testing Principals and Coding Kata

For the past few weeks I've been trying real hard to teach unit testing principles to my development group. Thinking on the subject I decided to create a workshop for the group to actually practice writing unit tests. Luckily, my managers gave me the approval and opportunity to spend a decent amount of time on creating a lecture and coding workshop for the subject. 

Watch it on Prezi

The following is the lecture I presented to the group last week. The presentation was accompanied by explanations and examples from the group day-to-day tasks. Most of the ideas and axioms presented were collected from books I read to better understand and improve my software craftsmanship skills. Primary books dealing with unit testing and tests in general are: Clean Code by Robert C. Martin, Working Effectively with Legacy Code by Michael Feathers, Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Robert. I've also covered few topics presented in blog posts from the hacker chick blog [1, 2] and Martin Fowler blog [1] (thank you, Uri).

A coding Kata was created to illustrate a small code base (legacy as it has no unit tests) of bank account operations. The logic, of course, doesn't really makes sense, but I used all the elements and principals most developers will encounter during their daily development tasks (Entity, DI, DAO, etc.). I've included a sample unit test for the PromotionService class so developers can learn by example when trying to write other tests. The Kata practices writing mock enabled unit tests using EasyMock focusing on IMocksControl and Capture scenarios. Some test cases were offering the option of using of EasyMock's nice mock (as a simple stub) or practicing strict mock of recording behavioral order.

The workshop took almost 3 hours to complete. Still waiting to get some additional feedback from the participants but so far all are positive ones. From what I managed to hear, people are discussing the topic and concepts I presented and I hope they will eventually agree with most issues. I have no doubt that I will keep having argues on the subject, but hopefully less than before (well, I can dream, right?).