The larger a company gets, the more time it must spend in internal communications to make sure everyone’s on the same page.
The lesson I learn from this is that leadership in small groups who remain focused on solving problems is more important than process or lack of process.
The good open source software and the good closed source software share this tendency: small groups, engineers unhindered by unnecessary complication and bureaucracy, strong leaders and clear goals.
I think there’s one other obvious thing that most people forget to mention: there should be a frontier, or unconquered space and challenge, to the project. That fosters a sense of both play and adventure, and we need that to really engage ourselves.
There will be a fair amount of talk in the future about creating winning software because right now, our software is good but not great. Just like our operating systems were kind of schlocky before Windows XP raised the bar, our software is kind of schlocky. It handles major use cases and outside of that, it may crash or behave unpredictably. It may just perform below the desired level.
Interestingly, the only solitary person who can ensure that good software gets made is the manager. The programmer can do so much, and then comes crashing up against standards or other people. Marketing can only do so much. Design teams can only do so much. But a manager can foster the right environment, and the engage his or her “user-centric” viewpoint to make software that treats the user right and does all of what they need to do.
But that, too, is a task that requires a sense of play, a clear goal, and discipline among the team, or even that grand vision does not get conceptualized.