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.

agile architecting

The whole IT world "is" / claims to be / wants to be agile today, which reminds me of the days when the hype was about multimedia ... every CD out on the market was multimedia.

But actually this title has quite some substance if you watch this presentation The evolving Guardian.co.uk architecture. A presentation worth watching from which I would extract these ideas:

• architects, don't underestimate developers when tech issues must be solved !
  
• having a parallel platform team to deal with non-business, purely technical stuff
• new architecture optimizations and improvements being much later needed than estimated
  

paradox

It's a bunch of smart people, I hear them all the time in meetings and I read their emails ... How can I say they are smart ... a good percentage of what they say I don't understand! They are the core that built and are now extending and selling a well known HP product. And they are polite and helping, which is another sign that they are smart ... I mean they must be smart, I feel it.

How come their frameworks are over-engineered, the code is full of dirt, the test coverage is close to zero? And something along this paradox to be tagged as sad: how come they are forgiving with this state of facts?

the young and the motivated

Its probably the young IT industry in Romania that makes recruiters add this sort of benefit in most of their emails and ads: You will be part of a young and motivated team.

I am looking forward for the times when I'll read this instead: You will be part of a very experienced team with great past achievements.

intuitive [/] emacs

... a screenshot of mcedit, no comment

new comers are right

They see the code base differently, they are unbiased: they don't know who owns a package, they don't know there are historical reasons why the code is so bad, they don't know the past trade-offs and political games, they are unaware of the dirty workarounds that still keep things moving.

You've been "contaminated" all this time you've spent in the project. You know package A is owned by the team lead so you won't review it harshly, you naturally justify the bad dependencies with the schedule pressure two releases ago, you got used to unsetting this environment variable and creating that magic file by hand each time you run a deployment and those worthless TODOs seem a natural code outfit, they almost please your eye.

New comers can't see the forest for the tree, but this makes them focus on every tree. And sometimes healing tree by tree is what gets a global healing effort started. What they see is the current technical debt at a granular level. They are not yet bored with the codebase so they are eager to find the problems you have long accepted.

Only if there was someone to weight their opinions against the contaminated ones ... and do it faster than the team contamination velocity.