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 :-) 

When Scrum will meet its death?

Hopefully soon.

Last week I read “What killed waterfall could kill Agile” post on “The Clean Coder” blog by Robert C. Martin (a.k.a. Uncle Bob). To quickly summarize the article, from my point of view: Building authorities over a process devoted to team decision might lead to the same dissatisfaction as it existed in the Waterfall process. While XP clearly indicates the development disciplines, Scrum seems like a buzz word for Project Management but misses the development part. Scrum Masters are usually Project Managers or Team Leader and the Scrum discipline drifts towards: managers - manage, developers - stay overtime to meet requirements.

My previews work place and at my current one, Scrum Masters are the team leaders. It’s not that they don’t manage Scrum, but don’t really care for code quality when tasks take bit longer than planned (ever heard the phrases: “We’ll write unit tests next iteration” or “We’ll get to that refactoring in future stories”). From my knowledge and understanding, the cost of refactoring poorly written code increases over time and adding too many coding patches can end up killing your product. Even so, every Scrum Master (or PM/TL wannabes) I met always tried to deal with my quality concerns by opening a bug/ticket to “track necessary changes” to modules we’re currently working on - but just complete the task (please!). My last work place even got to the low point of declaring that “team decides” is just a way to promote the process but we won’t follow it since the management will decide everything. Yep, they actually called the entire development group just to say - Fuck Scrum, we’re managers - you’re servants. Leaving me with the feeling that Scrum is a management process, not development process. 

Personally, I’m not a huge fan of processes (Agile Manifesto also states preferring people over process), but writing software in a team requires clear, shared guidelines. Software Craftsmanship is Scrums’ missing development disciplines. As a software engineer I want to dedicate as much of my daily work hours to do actual development. As a developer I want to be able to focus on delivering working, maintainable and reliable code. 5-10 minutes of daily Scrum meetings is the adequate amount of time developers should invest on project or task management. Developers should focus on delivering professional code - managers should focus on assisting developers doing so. Continuous Integration and Continuous Deployment methodologies allows developers to focus on code quality and less on the process. Write code, test it (unit, integration, system, functional) and fulfill your tasks as a professional developer.

At its current form, Scrum shouldn’t be kept alive. At Scrums’ current form we are still delivering medium software and call it Agile. If managers only wants to add another title (Certified Scrum Master) to their resume - fine. But don’t call your organization agile when you force your team to cut corners and deliver unmaintainable code base just so you can say we have a working product. I do wish to find a magical methodology that truly fits the needs of both software developers and project managers. So far, I haven’t found any.