Steven Sinofsky spent a lot of time at Microsoft (1989 to 2012), and wore many hats from programmer to program manager to general manager, across a wide range of products. The only thing he lacks in depth of experience is being at other companies and thus other corporate cultures. Nevertheless, he’s got enough experience to know that “learning by shipping” is about the only way you can learn how to write software.
Yes, you can read all about it in books. Yes you can study methodologies, you can learn programming languages, you can learn management styles. But in reality, the needs and realities of software are unlike other types of product development and engineering. Due in part to the nature of the beast, due in part to the nature of the business and market. Book experience is good, and a degree matters, but years of experience and actually shipping products across a range of teams and projects matters a whole lot more.
So… hint to you young guys: ship. Experience matters more.
Over my decades (yes I’m a graybeard) in software, methodologies have come and gone, and it’s always trendy to cling to the latest one. I recall so much time spent and wasted on these things. Oh sure, up in our ivory tower that’s fine, but someone has to pay to keep the tower lights on and the fridge stocked with Mountain Dew. Sometimes we have to set our programmer ideals aside and deal with the business realities of shipping.
Steven writes that it’s more important to focus on the work, not the methology. Very true. He picks the two big “opposing” methodologies of waterfall and agile, with waterfall representing the “old way” and agile being the new hotness. The funny thing is? These things only matter to people that care more about the process than what the process is supposed to produce. So you might get some manager that’s all hot and bothered about a “burndown chart”, but any programmer worth his salt would rather just get back to coding and getting work done.
In my experience with my own teams and in talking with my colleagues, most successful teams are those that are left alone to work. In many regards, it’s about letting the team find their own way. Oh sure, at fresh team with unknown people do well to pick some approach at the onset, and picking some formal paradigm is useful because hopefully then we can all start off on the same foot a little quicker. But to force the rigid process over the long term is not ideal. The team should be allowed to form and flow as it needs to, so long as there’s continued progress towards the goal.
Steven hits what it’s really all about:
In projects I’ve worked on that have spanned from 3 months to 3 years, the only constants relative to methods are:
- Establish the goals of the project, the plan, in such a way that everyone knows the target—execute knowing where you want to end up and adapt when you’re not getting there or you want to adjust the target.
- Create a project schedule with milestones that have measureable criteria and honestly assess things relative to the criteria at each of those milestones.
You need to know where you are going, you need to know where you need to end up, and you need milestones along the way to ensure you’re on the right path to get there. That’s really about it.
I would add that good communication is important too. You cannot work in a vacuum, and the parts and parties involved need to communicate and be sure everyone knows what is going on, including what might be holding them up. This is one part of the agile process (scrum) that can be useful to impose: the daily stand-up/scrum meeting. And it must be in that context with that structure, not just a generalized “meeting”. This is a good way for everyone to stay on track and on target. But precisely how this all pans out should be allowed to grow and change with the particulars of the team and project.
And to touch on tools, tools should be there to support the process, not dictate it. For example, if you start to use software tools that dictate an agile process, well… not only are you no longer agile (how rigid can you get!), but you won’t have any ability to change because the tools have forced you down a particular path that you cannot stray from (unless you abandon the tools). I’ve used tools that implement a strict notion of agile, with stories, a workflow, backlogs, etc.. And to some extent that’s nice, but often all you really need is a bug database with a way to group and prioritize and assign tasks. (I’ll plug JIRA because it’s honestly been one of the nicer and more flexible tools I’ve used; could be a bug tracker, a task manager, agile storyboard, whatever… you can make the tool work for you instead of you being constrained by it; I get nothing for this plug, just been a happy user).
So really, what does all this boil down to? Stop worrying so much about process and get things done. Your process will evolve. Yes a fresh team, a team not expected to last long because it’s a quick project, they do well to start out with a formal process. But after that, the process should not be the focus but only be an enabler towards getting the goals accomplished. Process is not the goal, it is not the end, it’s just a tool. The tool should be modified, molded, discarded, ignored if it’s not working in whole or in part. Let the team find their way and support them with what it takes to get things done.
We need to ship. Let’s not lose sight of that.