Four Pillars of Software Development

Doug Shimp — Wed, 22 Apr 2009 20:44:04 +0000

The purpose of this post is to consider Four Pillars of Software Development and Simpley Rules

Project Management is mainly about “managing the work” or stimulating the environment so the work gets done with minimal telling people how / what to do.
Source Control if it’s only one file then, I don’t need it of course it is always more than that as soon as it goes over 100 files it becomes a necessity.
Build automation (and repeatable automated configurations as a whole) shows up after source control and becomes a necessity around 500(pick a number that you think you will go crazy at) items or so. It is a number thing but, I can get by longer without repeatable automated configurations than I can without Source Control.
Test Automation this shows up as needed after 1000 plus code files. Test automation is all about feedback. When I say feedback it assumes people are already thinking in terms of interface design “start with the end in mind” if not then TDD/Unit must be purused because people are missing critical thinking skills.

Calling them pillars for complex software development that goes over 50,000 lines of code is appropriate. If it is something less than that then they are not pillars because I can make do without them. The way I see it they show up as each hurdle of complexity pushes me over the edeg. Here is the order that the Pillars show up in and Simply Rules for each pillar’s primary purpose.

Project Management – “Make it visible” then emergent order can happen
Source Control – “Create a Known Center” then we can work from a place of stability without getting lost in our own mess.
Automated Deployments/Builds – “Work from repeatable base lines” then makes changes from there
Automated Testing – “Keep stuff we want” modify to add new behavior. Sometimes through open/close and sometimes refactoring to accommodate new which yes, is recursively open/close but, not really

Each pillar is to help shorten feedback and bring focus so that we “pay attention and adapt” .

So my take is that if you are something over 50k + lines of code then these are pillars because you just can’t move much beyond that without the tower of code falling over. Each pillar shows up as you scale the pile of complexity you are dealing with. People also increase the complexity and require more structure to work within.

Ideally, I want “just enough structure to run rampant in“.

Make It Visible

Doug Shimp — Wed, 15 Apr 2009 04:39:05 +0000

This is perhaps one of the most obvious yet, continually overlooked rules. Visibility is key to getting the emergent behavior we would like to see on teams so that we don’t have to resort to task assignment. For conceptually heavy work this is especially true. Transcending this pattern requires a mechanism to make things visible.

For a group of people, when the visilbility of the work between is poor or hidden then the collaborative interactions are correspondinlgy very poor. This holds especially true for work that is largely coneptual in nature.

By making things visible people have a chance to self organize to the work and pitch in without being told. They work together collaborative to do the job. Making things visible in the right way is the challenge of management.

Advanced Topics In Scrum » Simple Rules

Four Pillars of Software Development

Make It Visible