How Software is Built

A blog forum to provide deep dive analysis and community conversations about software development models. For more details click here.

As I begin this exploration, I’d like to start by briefly laying out my own professional history. I’m not an academic; I’m a builder. I began my career in 1976 as the only data processing (as they called it then) person in a small electronics manufacturing company. I worked designing and developing software for internal corporate use for about 5 years, then I made a conscious switch to development of commercial software for PDP-11s running RT-11 and RSTS operating systems. Once desktop computers became prevalent, I focused on software for those machines. My last 15 years or so have been spent primarily in engineering management roles, where I have been responsible for managing teams to deliver commercial software running in a Microsoft Windows environment. I have some gaps in my experience in that I have very little exposure to UNIX/Linux, and no experience developing software in an open source environment. I have no axe to grind, however, and I’m coming to this exercise with an open mind. Let’s see how open and closed source processes differ.

To gather the data I’ll need, I’ll be depending to a large extent on interviews with development professionals. I expect Microsoft to give me access to product managers and developers, and I hope to convince other closed source companies to give me similar access to their staffs. I’ll interview open source managers and developers as well. I’ll be focusing roughly on the following questions:

1. How are features for the first or subsequent versions of a product determined?

2. How are features architected and designed?

3. How does a feature go from an idea to something being coded?

4. How do all the “ity’s” end up in the product (security, quality, reliability, scalability, etc.)?

5. How does documentation and localization get done?

6. How are project schedules formed and tracked?

7. How are projected release dates communicated to the public?

8. How does a product transition from Beta to release?

9. How do bugs get reported and fixed?

10. How do users get access to the source code?

11. What do users do with the source code?

We all know that processes differ from team to team, regardless of whether the code is being developed using open source or closed source methods. Since that’s true, I’ll need to access several different teams on both sides of the issue so that I can identify broad trends and attributes of the two approaches to development, and avoid drawing conclusions based on the idiosyncrasies of 1 or 2 teams. I’ll need your help with that.

Please let me know which companies you would like me to examine on the closed source side, and which projects on the open source side. If you are personally involved in a development project of either type, can you help me get access to others on the project? I’ll do a condensed conversation dump to this blog after each interview, and I’ll identify the person I interviewed as well as their company or project affiliation. If you think your process is great, let’s get it in the mix.

Posted by Richard on Tuesday, April 3rd, 2007


You can follow any responses to this entry through the magic of "RSS 2.0" and leave a trackback from your own site.

Post A Comment