Today, I read an article by Gregor Dorfbauer of Usersnap called 8 GOOD HABITS IN WEB DEVELOPMENT.

Because what I have to say on the matter would make a bad comment (tl;dr coming up), I decided to post it on my blog and refer to it.

While there are quite a few good ideas, it does seem that we have different goals. Let me address my ideas point by point.

1. Use a Bug Tracker

I agree wholeheartedly. But I don’t agree with the workflow presented. For most working teams I’ve been in, there’s no “person in charge of fixing ‘it’”. Whoever is next in line to pick up a task, picks it up. If the task is “fixing a bug”, said person fixes the bug. I also disagree with the “user story” format, for most kinds of bugs the “action, expectation, outcome” format is the best.

Also, humour is a good thing, but not in the commit messages. Same with insults etc. A nice summary is found at Tim Pope’s Note About Git Commit Messages. If humour makes the message easier to understand, by all means, one should use it. But it usually obscures things.

2. Take responsibility

That works if features/user stories are small enough and can be handled in one or two days by a developer (perferrably pair). And if they are able to break down user stories (features) in small enough tasks that are most likely finished at the end of the day. If they are working with a ticket system, there’s no reason to push work on others, but have everyone pick their tasks. Same goes for a Scrum/Kanban board. Pull vs push helps a ton! (For a definition of “finished”, please check the point “Testing”.)

Another aspect is that the developers should be involved in designing features. And they should make themselves heard if they think that the feature they just heard about is, let’s say, questionable. A different view and a following discussion brings insight and helps do develop understanding of the whole product and processes.

3. Fix and test

Yes and yes. But there’s depth missing for me. First: create Unit Tests. Make them small, fast, concise and descriptive. Second: write stack/functional tests that make sure that the unwanted behaviour is not reintroduced. Third: make it part of the acceptance test suite/protocol. Only if all three modes of tests agree that the feature is working as intended, then a feature or bug is “finished”. For a task, Unit Tests may suffice.

4. Plan

Yes. But don’t forget to involve developers early on, else everyone planning might be unpleasantly surprised by estimates and actual costs (time) for a feature.

5. Single Sign Off

That paragraph rubs me the wrong way. It smacks of a position that was called “Delivery Manager” by a company I won’t name here, and he was responsible for implementing Scrum, internal process management and release planning and improving productivity. It ended badly.

For web development, I would rather suggest something like Scott Chacon writes about in Github Flow. (Don’t confuse it with git-flow, which is trying to solve a social problem with a technical solution.) In web development, one wants to deploy continuously. Especially if work is done by a small team, finding someone who can “sign off” a release will suck, if said person is on sick leave, vacation, congresses, heck, if that person is on lunch break.

In web development, it is smart to implement the following two things: Continuous Integration and Continuous Deployment. And implementing something similar to (or exactly like) the Github pull requests, and rule that the authors of the pull request should not merge and close it, but others in the team should. With people handling those tasks responsibly, it will result in a regular and efficient code review. And if tests are missing, the reviewers must not merge the request. But as soon as the request is merged into master, all tests have to be run. On success, the current master branch must be deployed immediately.

This will mean that occasionally a useless feature will be shipped. But everyone will just learn from that experience. If the team is using enough tests, and is fast on reacting to user complaints, no (lasting) harm will be done.

And in the end, if the team is using Scrum, there is one Person responsible: the product owner. But then he’s only responsible for accepting or rejecting a feature. Not for the rest of the process.

If there are reasons that keep the team from doing real continous deployment, using a staging system and a process where the testers can release feature by feature is helpful. Most of the time it is better to live with a short lived feature that users are not happy with – In contrast to deploying huge releases with a large scope every once in a while.

6. Create Feature Teams

Yes and yes. Nothing to add.

7. Did We Mention Testing?

Yes, I guess the article did and I did. Let’s leave it at that. The topic is huge.

6. Always Keep Optimizing

I don’t like the word and it’s connotation. (Suggested reading: Premature Optimization). But then the article goes into more detail, and becomes a bit clearer. Still, I have issues with the way it is worded. Let’s analyze:

1. Make it work.

Yes. But what is “it”? The best way to do it is: Make sure that the test coverage is alright, make sure that the code works as intended. A good way is to use Test Driven Development: Make it red (write a test for a future feature), make it green (implement it so the test passes.)

2. Make it right / beautiful.

No, no, no. Make it right the first time. Implement it to specs (tests), before going to the next step: Refactoring. Refactoring is not making it beautiful. Refactoring is taking away until nothing else can be taken away lest it breaks. Avoid repetitions, redundancy, or violating the SOLID principles). Also a good idea is to practice the ‘boy scout practice’ of Clean Code fame: When touching a piece of code, leave it neater than you found it.

3. Make it fast.

No. Just don’t. If there are no problems, it’s fast enough. If you suspect or have problems: First step is measuring how fast a newly implemented feature’s parts really are.Next step is measuring how fast the whole stack is. If there are real performance issues, then it’s time to identify them. Stick to the paradigm: Make the common case fastest. Check for alternatives in flow and algorithms before trying something like re-writing it in C. But please, for the love of George (or the FSM), don’t just optimize for optimization’s sake.

Here ends the article.

All in all, an interesting article, but for me it just doesn’t hit the spot. Good basic ideas, though, and it got me writing again :)