I was wondering this weekend, "What was the first software development methodology?" Luckily, somebody significantly more determined than myself already did the hard work. Dr. David F. Rico has identified a timeline of software development methodologies, at least in broad strokes. My favorite part of this paper is how he broke down each methodology into the Era and identified Market Conditions that surrounded each methodology. While reading the list I laughed at the fact that the first two methodologies, Flowcharting and Structured Design, were aimed at fighting unreadable and complex programs.

Now to enter the controversial and confusing world of emotions: We had some strong showing of emotion on our team this week and I was so excited. Finally breaking through the shell of avoiding conflicts and feelings. Ooh, the F-word. Feelings . A scary topic for most engineers I know, including myself. I was a firm believer that Feelings were an engineer's worst enemy. Even worse than the F-word is the E-word.

Roy reminded me of this great article this week. It's long, but has some great content. If you want to get the bonus 2 and 1⁄2 rules, you can watch the video: 21 Rules of Thumb for Shipping Great Software on Time Jim McCarthy, Microsoft Corporation Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager’s ability to focus on a few critical and conceptually simple things.

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. (iii) Design and build software, even operating systems, to be tried early, ideally within weeks.

This is a great post by Pierre Raynaud-Richard at Facebook about their Engineering Culture; specifically Code Ownership. There are a lot of important ideas in here and I encourage you to read it thoroughly. Here's one of my favorite sections: The culture of the "code expert" results in a world of sclerosis and stagnation where really bad things can occur. Here are just two examples: The ideas of the expert are no longer challenged.