agile is not communism

I enjoy a lot articles that mix social and software sciences. And I think they provide much value to the software community cause software is built by people (still, as of 2010), so their psychology and their interactions drive the software development.

This is a lightweight reading for the morning in this respect: Agile is Not Communism. And even if the author does a pretty good job of proving there is not much similarity between Agile and Communism, this phrase stayed with me: Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either.

If you are like me and feel that today's Capitalism is not far from failure too, then take my advice and visit Greece, while it still has its islands ...

But since it's still early morning and we need our optimism for the day, take this quote from John Kenneth Galbraith: Under capitalism, man exploits man. Under communism, it's just the opposite. ... uhh, did I say optimism?!

next to binaries

There are not many things you can deliver to make your customers happy: one is definitely the code, and the 2nd are the docs: user-level documentation.

I've been recently asked to review the part of the documentation for the feature we are owning, and it was a surprisingly fun thing to do. I had no different feeling when reviewing it than the one I have when cutting some clever piece of code. It felt like putting the cream on the cake. It was an easy win: improve a deliverable that the client will definitely touch, cause our customers do use the documentation.

This line probably sounds right: good software comes with good documentation. But it's the other direction I am interested in exploring right now, what can documentation do for the code?

When evaluating new software I could use, like a web framework, those that have good docs have a much higher chance of getting in my toolbox. I start by looking for a section that would give me a basic setup fast, like Up and Running in Ten Minutes. Then I am awarding additional points for an introductory video. Then I will scan for How To-s for sensitive problems and references like configuration file and API ones. I admit though that once the tool is in my inbox, a weak online help won't make me drop the tool, as long as the help is not annoying.

For software developers good documentation means marketing. You'd want to grab market share, which for freelancers especially translates into increasing the number of users of the software. My advice is Write docs and keep them up to date, ask for reviews for even better docs.

Disclaimer: this post has not been reviewed before publication, hence it might contain some typos. No excuse though if it contains stupid ideas.

customers have a say

They are the most useful slides I've seen in quite a while. No need for anyone to narrate them, no regrets that you were not there when the presentation was held. Cause they are self contained, straight to the point.

If you asked yourself at a certain time What feature should we implement for the next release? then these slides are for you. No guessing, no gut-feeling, but real-world data ... from those who dislike wasting extra clicks, who feel pain because you don't support the new device out on the market, who would love your shiny feature even more had you documented it. Your customers.

the essence of agile

For those who love agile, practice agile daily, feel it in their bones but have not been so agile to find the site with the essence, here it is http://agilemanifesto.org.

a low importance misfeature

JDoe had a long day, he's been debugging and re-installing and patching for the last 10 hours. And it all worked like magic in the end after a simple reboot. He had spammed quite a few inboxes in the process, so he is thinking now he should probably send a final email saying Hey, it all worked out after a reboot, thanks for your help.

Is this important enough to warrant a new email? Wouldn't he bother the team even more? So he decides he will send the email with low importance ... see, every problem has a solution.

... is it so? What do you do when you get a low importance email in your inbox, do you skip it? Do you simply delete it? Or you have a filter that does this for you? I admit none of the above in my case. I read all my daily 30 something emails in the order I get them, normal, high or low importance ... indeed in some cases I go to high ones first, rarely though.

Weird enough, low importance emails draw my attention more than normal ones thanks to the nice little blue arrow in front:

AND my email client pops up notifications for low importance emails just as for the others, instead of letting me focus on tasks with a normal importance at a minimum.

So,  
Dear JDoe,


I am sending this normal importance email just to you. Please save some of my time by sending a regular email only to the ones that tried to help; forget low importance emails.


Thanks,
Lucian

less agile?

It's a stripped down version of Scrum what we are doing. I mean, not that we wanted to change anything, but we had to adapt.

Cause we did not have a tester from the beginning of the project. So we tested more.

Cause we don't have stand-up meetings. But our desks are practically touching each other, so everyone knows what the others are working at, all the time. I know, you can't afford this luxury, but we are just a team of three. Blockages ... send an email and wait, be inventive, find something else to work at.

Cause we don't have a one-sprint long backlog. But we are continuously eliciting requirements from the over-the-ocean project manager, team leader and GUI specialist. They know what features the clients want. That's where the final say on GUI usability and consistency is ... still we are continuously pushing to have a sprint backlog.

I'll tell you what's better than a traditional stand-up meeting. It's our weekly sync where we started  yesterday to use a virtual room to demo our progress. That's my favorite side of Scrum, the demos. Those at the end of the sprint. But now we are doing them weekly, I think this keeps the momentum.

I know, it might not be Scrum, but we are agile, in our own special way.

paradox (II)

The original paradox urged me to look for some answers. I've been thinking but mostly I've been asking around. I am not alone in this as a few others in other software companies could tell the same kind of stories.

The most mentioned reason is boredom. Developers' boredom. Laziness. Not incompetence. Which is sad. You can do a thing right, still the day is too alike the others, so you do a poor job just to finish earlier, or cause you've done it so many times before.

The original post title was Don't hire contractors ... It doesn't say it all, but it's catchy and with a reason. It turns out that in case of my project a major cause of poor code was the work of contractors. Not that they were incompetent, not they were even bored (cause those were the times in the lifecycle of this project when no one could get bored), it was the market forces that made them write code fast, not test and ship early. But they grew and got market share. (See here a post that says they might have even chosen the right path from a business point of view). They provided a job for me, the one who swears at their code.

No automated tests, no code reviews, no time for a best-practices catalog, an outdated wiki. Great programmers. This is the recipe for a best selling product !?

Anyway, back to the original title: if you can afford to ignore the business and only care about code, don't hire contractors if you don't have a good development process to oppose some forces to their fury of producing lots and lots of code. Contractors come and go, so they have to produce code to justify their cost (Permanent employees have to do that too, but they are not under the same time stress. They are hired forever, or until a bad review following the last bad review comes, which might take two years in some companies).

Build contractors a light but working development process, allow them to be creative, but don't let them fool around with code, nor leave garbage behind. Or else a developer like me in a post-contractor era will complain that the code is poor and lose time solving paradoxes instead of producing code ... top-quality code.