| 1 |
>> > kdepim devs are just making a simple classic mistake that's |
| 2 |
>> > been made over and over and over again. Developers do not learn from |
| 3 |
>> > history, every time this mistake is made the team doing it thinks |
| 4 |
>> > *they* will be different. |
| 5 |
>> |
| 6 |
>> What is that classic mistake? Is it the shark jumping thing? |
| 7 |
> |
| 8 |
> No, the mistake is the mistakes that are always made on the second |
| 9 |
> big project. You'd have to read "The Mythical ManMonth" to truly do it |
| 10 |
> justice (it's a really good book for developers btw), but in a nutshell |
| 11 |
> it goes like this: |
| 12 |
> |
| 13 |
> For your first big project, you will proceed very slowly and carefully |
| 14 |
> and not take on too much, as you know you know nothing. You will |
| 15 |
> probably make a project that does one thing and does a decent job of it. |
| 16 |
> |
| 17 |
> Enter the second project. Buoyed by the success of the first, most devs |
| 18 |
> will try and build something that is waaaaaaaaaay beyond their |
| 19 |
> capabilities - I mean, how hard can it be right? It will over-reach, be |
| 20 |
> unbuildable and timeframe estimates will be bat-shit crazy insane. |
| 21 |
> |
| 22 |
> The attrition rate of second big projects is rather large. |
| 23 |
> |
| 24 |
> Enter the third project. Humbled by the experience of the second and |
| 25 |
> still feeling quietly (and realistically) confident by the first, most |
| 26 |
> devs will settle down to something useful, of wide scope and still |
| 27 |
> achievable. |
| 28 |
> |
| 29 |
> This same rule seems to apply to almost every project a bunch of humans |
| 30 |
> could tackle. |
| 31 |
|
| 32 |
Brilliant explanation. Thank you for taking the time to write this out. |
| 33 |
|
| 34 |
- Grant |
Archives