June 7, 2009 21:55
Whenever I hear the word "agile" I reach for my revolver.
A huge pile of chest-thumping and vapid articles about benefits - and a lot less about pitfalls. Often, people just say "uhm, you know, it's not a silver bullet" and "just don't change the process" and then you have to glean the rest yourself.
So google for pitfalls of agile and read over, learn the salutary science of Agileology, and this post will be sitting here until you're done.
May 24, 2009 20:30
If you've ever played chess, you know how important openings are: castle early, protect your king, get some control... Time-proven, standard ways of starting a game, they lay a foundation for your victory.
It's similar in software development. Before you start a project, there's a lot of pretty standard things you should think of - from development process to architecture to testing and deployment.
These are your openings. More...
March 30, 2009 20:56
There are three types of development:
- (Re)implementing the functionality
- Bugfixing and refactoring
Of course, sometimes your "implement the stuff" timespan can be interrupted with high priority bugs. And indeed your redesign sometimes can come along with new functionality from the get go.
However, it is important not to mix the approaches you use in each case. More...
February 1, 2009 22:47
Frantical coding hasn't made the list.
November 23, 2008 17:21
In the very first lines of the movie "Rounders", you can hear Mike McDermott saying: "If you can't spot the sucker in the first half hour at the table, then you are the sucker."
Listen, here's the thing. If you can't spot the leader in the first half hour at the table, then you are the leader.
October 19, 2008 14:38
In the poker game of software development, team leaders are the rake.
Of course, not only have we different assumptions about the skill set of a team lead but understand the role in different ways. So let's talk here about those team leaders who gather estimates from the rest of the team, send daily progress updates to Big Bosses, explain the imperial decisions, communicate with business analysts and so on.
Sometimes it's called "project management", "project coordination", you name it.
I'm not saying the approach is bad - it works fine for a lot of software shops, there can be perfectly valid reasons for adhering to it, and we even seem to get used to this state of affairs. But the role is generally understood more as a role of someone blocked up with paperwork, while some (most?) of that paperwork can be done more efficiently.