A while back, I started a site called Shaping Software. The purpose was to create a collection of little nuggets on lessons learned from designing, building, and shipping software.
I ended up writing more than 100 articles on software development (browse the archives for a quick view).
The didn’t maintain the site. For one reason, I wanted a timeless depot, and I wasn’t sure how timeless it could be. Another reason is the site didn’t take off the way I expected. For example, if my MSDN blog generates 1000’s of visits a day, Shaping Software was in the 10’s per day.
Looking back, I think I learned important reasons why it didn’t take off. I didn’t name titles very well. It’s not always obvious what’s inside. Also, I didn’t always elaborate on topics that needed more elaboration to better understand and appreciate the nugget of knowledge. On a very practical, SEO side, I didn’t apply any SEO knowledge and I didn’t build any backlinks. Given what I know now, I probably should have continued to groom and to grow it.
There will always be a need for learning how to shape software with skill and there is an “evergreen” body o timeless principles, patterns, and practices … that is not well known. It’s an art and science and there is always a gap between the state of the art and the state of the practice. Principles, patterns, and practices at our fingertips help us reduce that gap.
Anyway, here are 30 nuggets from Shaping Software that you might find useful:
- 4+1 View Model of Software Architecture
- 5 Ways to Manage Complexity in Software Architecture
- Application Scenarios Model
- App Types, Verticals, and Scenarios
- Best Practices at Microsoft patterns & practices
- Constructive Criticism of the Waterfall Model
- Engineering Practices Frame
- Evolutionary, Incremental, and High-Risk
- How To Bring Experienced Engineers on Board
- How To Cure Optimitis
- Key Project Practices
- Knowledge Areas, Capability Levels, and Ladder Levels
- Macro and Micro Software Processes
- Make a List of the Jobs to Be Done
- Microsoft patterns & practices Solution Engineering
- Mission Impossible
- MSF Agile at a Glance
- Organizational Structures to Support Product Lines
- Periodic Design Refactoring (How To Avoid Big Design Up Front)
- Personas at Microsoft patterns & practices
- Requirements Types
- Scenario and Features Frame
- Shifts of Power (Ward Cunningham's way of describing what drives the requirements)
- Software Product Lines
- Source Code Reuse
- Waterfall in the Large and in the Small
- What is Systems Architecture
- Why Do We Need Software Architects
- You Can’t Evaluate Architecture in a Vacuum
Probably, the most important article to read (and re-read) is:
I find myself still using and referring to many of the ideas on a regular basis, whether it’s explaining to somebody why you can’t evaluate an architecture in a vacuum, or what shifts of power mean to software, or how to avoid Big Design Up Front, or what the different types of requirements are, etc.
I have to wonder whether it’s worth reinvesting in it, as a true repository of timeless insight and action for the art and science of building software.