Archive for November, 2011

If Cars Were Software

Coupling & Cohesion: “We installed your new radio. The tuner is in the trunk, we put the amplifier in the glove compartment and integrated the CD player with the carburetor.”

Single Responsibility: “Yes, that’s by design. The power windows go up and down as you press the accelerator.”

Open-Closed Principle: “To install your ski rack, let us begin by rebuilding the roof.”

Liskov Substitution: “It looks like a timing belt but behaves like a seat belt.”

Interface Segregation: “The lever to the right of the wheel indicates, switches wipers on or off, opens the trunk, controls A/C temperature and now let me show you  how you use it to input destination addresses for the GPS …”

Dependency Inversion: “I’m sorry – we can’t replace the battery. The headlights will only work with this particular brand.”

Consistent levels of abstraction: “By rotating, the pinion engages the teeth on the rack, thus translating rotational motion into linear motion which results in changing the angle of the front wheels relative to the back wheels. This is how you go left or right by turning the steering wheel.”

Advertisements

November 9, 2011 at 7:44 am Leave a comment

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

Gave this presentation at this year’s Agile Vancouver conference.   Thank you everybody who attended – much food for thought and ideas in the discussions afterwards. The slides can be found at http://www.slideshare.net/rreppel/why-theyarentbuyingyouragileandhowtomakethemloveit .

If Agile works, why isn’t everyone doing it? Or, as Agile has become fashionable of late, why all the lip service without the expected amount of real change? This talk makes the argument that it comes down to trust and presents tools and examples for building and keeping trust. The focus is on how to project plan and design applications in a way which, wherever possible, avoids putting stakeholders into situations which require trust in the first place.

In a nutshell:

  • Own your stack. If possible, use one co-located team per bounded context and architect systems in a way which allows developers to easily write end-to-end tests and do releases.
  • Make sure you and your stakeholders have a shared definition of what success looks like. Are you measuring the same things?  For example:  “Diligence in planning” vs. “Adaptability when responding to new knowledge”:  In light of the former, finding something unplanned-for is failure. For the latter, it’s learning and success is measured by how well the new knowledge is assimilated.

November 7, 2011 at 7:24 am Leave a comment


Twitter

   @robertreppel