I’m going to talk about some reading material and my own ideas on the software development process:
- Hackers and Painters essay by Paul Graham
- Creative Selection by Ken Kocienda
- Facebook mobile development article by Android Authority
- My own thoughts
“Hackers and Painters” by Paul Graham
This is a great essay in which Paul Graham sees hackers as having more in common with painters than mathematicians and scientists in the field of Computer Science. He extols the practice of tinkering and making rather than rigidly formally designing everything ahead of any code writing. He also talks about big companies often crushing hacker creativity through designing by committee and layers of product managers that ends up with mediocre software.
Creative Selection by Ken Kocienda
In his book Creative Selection, Ken Kocienda describes a software development process that seems compatible with the hacker ethic. The book focuses on the latter years of Steve Jobs’ time at Apple, and in particular during the early iPhone development. Ken describes a system of Directly Responsible Individuals (DRIs) that were responsible for particular pieces of functionality. Steve Jobs, the Apple CEO, would talk directly to the DRI of features and their opinions would be most important. There was a remarkably thin hierarchy and no product managers. At that early stage, there were about 8 software engineers that would be paired up with designers. Above that there was a manager that oversaw the software engineers and a manager that oversaw the designers. And then above that there was Steve Jobs. The development process involved a lot of prototyping and frequent demos. I’ve seen a few interviews with Ken but this is my favourite:
Andreessen-Horowitz page for the interview:
Book website: http://creativeselection.io/
Facebook mobile development
Facebook, not surprisingly given their original motto of “move fast and break things”, have a very agile development process:
“… everyone can work on what’s most pressing for them all the time, and that every other part of the business knows what they are doing. There’s a high level of ownership for each engineer, and everyone is ultimately responsible for their own work. Not only does this make the company more agile, but it also hopefully increases workplace satisfaction. No one is just a cog in the machine.”
“… anyone from anywhere within the organization could suggest an idea for a new feature, and then get to work on that if given the go-ahead. Sometimes this might even develop into its own separate app! Facebook is much more a collaborative project than the top down enforced vision of a few people (or one person) it is often portrayed as.”
My own thoughts
My own personal angle on this, which I don’t see getting talked about a lot, is related to the effects of having developers being passionate about their software and loving what they do. In my experience this makes all the difference. When a developer is passionate about their software, they will put more effort on the little details that turns good software into great software. Obviously there needs to be the correct environment to cultivate this passion for the work. In my opinion good software development requires dedicating large blocks of time without distraction to get in “the zone” where productivity is high. In my experience, most individuals that reach an elite level in their field (be it software development, entrepreneurism, science, sports or anything) have an almost obsessive mindset where the pursuit of their goals consumes their life.
Regarding the DRI concept, I will add that leadership is important for a software developer. Not necessarily leadership as in managing other people but leadership as in taking responsibility for your area of code/functionality and using initiative to be proactive in the evolution of that area.