AgileBCS

We met to discuss the first three chapters of Driving Technical Change. Some common themes in our experiences emerged.

Not everyone who’d read the book was able to attend. So, if you’d like to share your take on the book or your experiences related to the subject of the book, please do so in the comments.

What follows is a recap of the March 17 meeting:

Robert: the author mentions that unit tests aid migratation between versions of external libraries. Ben: unit test suite helped migrate between API versions of Flickr at prev job.

Ben: Can be difficult to sell to customer’s internal dev team. Sale relies on ability of PO to pitch.

Ben and Robert both guilty of pushing a solution instead of speaking about needs/problems. Robert: this is the central thesis of the book Resolving Conflicts at Work

Ben said something about taking for granted improvement through efficiency and reliability (maybe we can get him to elaborate on this).

Ben and Robert have both been a PITA to someone else. Robert: I’ve definitely been the stodgy bastard unwilling to adopt something (i.e. distributed version control).

Identity shifts. We know people who have tagged themselves as an “x” language guy. Zealotry. Dogmatism <- salesmanship. What are they selling?

Ben: Continual learning is a recurring theme in professional development literature.

Robert: I.E. Pragmatic Thinking and Learning I think.

Solving a problem or pushing a solution? Mongo DB is webscale. Mongo DB kool-aid.

Ben: Enterprise clients are buying Ruby.

Robert: Ruby is just another language w/o Rubygems. Same deal w Python and Cheese Shop

Ben: Have to gauge whether there is a problem to be solved—from the client’s perspective as well as yours (if it ain’t broke …)

Ben: Some clients won’t allow SVN externals. Ryan: Doesn’t that defeat the point of repositories.

Robert: Gauge whether the solution fits. Ben: Have to work in the context of the client’s business practices.

Ben: Take inventory of skills of team. A place wanted me to implement something that everyone else didn’t have the skills or experience to maintain. Quasi hobbyist perfessional development.

Robert: Analysis and design should be taught over patterns. Ben: A&D should be taught—in the context of retrospective.

Ben: Prescriptive approaches can burn you.

Ben: Kept rearchitecting something on solo project. Got thrown a curveball later on when new requirement got added. Lost some stuff.

Ben: List options. Robert: Hard part is getting past your own subjectivity; your preferences.

Sidenote: Ryan and Robert both had some issues getting up and running with Test Drive ASP.NET MVC.