30 Nuggets on Software Development from Shaping Software

  • Article

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:

  1. 4+1 View Model of Software Architecture
  2. 5 Ways to Manage Complexity in Software Architecture
  3. Application Scenarios Model
  4. App Types, Verticals, and Scenarios
  5. Best Practices at Microsoft patterns & practices
  6. Constructive Criticism of the Waterfall Model
  7. Engineering Practices Frame
  8. Evolutionary, Incremental, and High-Risk
  9. How To Bring Experienced Engineers on Board
  10. How To Cure Optimitis
  11. Insourcing
  12. Key Project Practices
  13. Knowledge Areas, Capability Levels, and Ladder Levels
  14. Macro and Micro Software Processes
  15. Make a List of the Jobs to Be Done
  16. Microsoft patterns & practices Solution Engineering
  17. Mission Impossible
  18. MSF Agile at a Glance
  19. Organizational Structures to Support Product Lines
  20. Periodic Design Refactoring (How To Avoid Big Design Up Front)
  21. Personas at Microsoft patterns & practices
  22. Requirements Types
  23. Scenario and Features Frame
  24. Shifts of Power (Ward Cunningham's way of describing what drives the requirements)
  25. Software Product Lines
  26. Source Code Reuse
  27. Waterfall in the Large and in the Small
  28. What is Systems Architecture
  29. Why Do We Need Software Architects
  30. You Can’t Evaluate Architecture in a Vacuum

 

Probably, the most important article to read (and re-read) is:

Lessons Learned in Microsoft patterns & practices

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.