On Wed, 22 Feb 2012 09:26:01 -0800 Grant <emailgr...@gmail.com> wrote:
> >> Likewise for debugging the kdepim mess when it was already working > >> well in the old kde. What ARE they thinking? Reminds me of our US > >> Congress, all advertising and no product. > > > > kdepim devs are just making a simple classic mistake that's > > been made over and over and over again. Developers do not learn from > > history, every time this mistake is made the team doing it thinks > > *they* will be different. > > What is that classic mistake? Is it the shark jumping thing? No, the mistake is the mistakes that are always made on the second big project. You'd have to read "The Mythical ManMonth" to truly do it justice (it's a really good book for developers btw), but in a nutshell it goes like this: For your first big project, you will proceed very slowly and carefully and not take on too much, as you know you know nothing. You will probably make a project that does one thing and does a decent job of it. Enter the second project. Buoyed by the success of the first, most devs will try and build something that is waaaaaaaaaay beyond their capabilities - I mean, how hard can it be right? It will over-reach, be unbuildable and timeframe estimates will be bat-shit crazy insane. The attrition rate of second big projects is rather large. Enter the third project. Humbled by the experience of the second and still feeling quietly (and realistically) confident by the first, most devs will settle down to something useful, of wide scope and still achievable. This same rule seems to apply to almost every project a bunch of humans could tackle. So back to KDEPIM. The state of that project, the amount of bugs it has, the attitude of the devs, the state of the migrator scripts, the way Akonadi can suddenly go nuclear on you and eat your kittens, the mysterious disappearing mails from imap stores, and more, all of these things point straight to second project syndrome. The devs bit off way more than they can chew and now it's biting them back. But it can be fixed. All it needs is a smart leader with the balls to nuke all the crap code, put up with the inevitable whinging, and get the project back on track with a set of realistic goals. This might well mean chucking all of Akonadi away and admitting to themselves that they must stick with lots of flat files for a while longer. > > - Grant > > > > This is their second big project - the most dangerous one a dev will > > ever work on. Frederick P. Brooks has it all covered since the 70s. > -- Alan McKinnnon alan.mckin...@gmail.com
