Borland Software Craftsmanship by James O. Coplien 1994
Software Craftsmanship refered to this paper. It sounded interesting so I read it – and it’s quite short. You can find the paper floating around in the web – just do a quick google search.
The paper is about a product Borland built – a spreadsheet application for DOS. The product was really well received but one thing was different. The team was really small:
core team = 4 people (architects, domain experts, UI)
The description of the core team was interesting. These were actual experts in their fields. Iirc, two people worked on spreadsheets before in depth and knew which problems to anticipiate. Also the focus on UI was excellent. It showed that they cared about their users.
built three prototypes
The mythical man month’s throw one away. Brooks later revised this advise about the mythical man month. Nonetheless, even a team of experts did it. There’s this saying: when the rubber hits the road. I think it is also true for software. You can sit around and designing the perfect architecture but you will only see if it works either if a) you copy a existing design or b) you try it out.
- four additional developers after after 6 months
- 6 months later, QA entered
- active beta user program
The early user involvement was certainly an important part. I’ve seen it over and over again and just seems to work. I even did it when I solved problems for my employers or a community. It just works.
- strong communication & team
- Product and project manager were both technical and worked together
- QA is tightly integrated
- Roles were clear
- CEO is bought in
These points are often neglected by technical people. As a quality manager I spent the majority of my time correcting these things. Communication, team work, buy-ins. It’s incredible how good a team can be supported if the environment is ready for it. Or simpler, if you put a horse in a cage it won’t win the race.
- Personal responsibility from each team member
- People do the stuff they’re good at
- Highly iterative
Also some themes I’ve seen over and over again aka skin in the game, using strengths and don’t sit in the ivory tower.
Daily hour long meetings about architecture & structure
This was the most surprising part. They spent about 4 – 6 hours each day sitting around and talking about architecture and structure. Each person did their own implementation but they worked out the system together. One of the most striking ‘features’ of this structure is that they had about 4 hours at max to do actual coding. For some it may sounds less but you can’t concentrate 8 hours a day. I’ve written about this multiple times but I often spend 90 minutes concentrated on some problem and subject and advanced more than my peers who spend 4 – 6 hours on it. It’s about quality not quantity. And the final slogan: Work smart, not hard.