The long way through Software Craftsmanship

Jan 1, 0001 - 2 minute read - Comments


published: false categories:

- draft

curiosities - so early, they talk: * about testing, reproducing cases: ensuring quality * store documentation and update it incrementally (in paper) * store versions of the software: version control system (VCS)

ideas to talk about: * no silver bullet - essence and accident - how to measure performance without control groups? - candidates: - the social coding (not silver bullet, still) - higher-level languages and frameworks (scala, play; python, django; ruby, ruby on rails) - open source packages * brooks’ law * nine women cannot make a baby in one month: the non-parallelizable tasks of a project * chapter #2: the idea of the waiting patrons on the french menu * investing a part of your time to sharpen your tools * * hypothesis: was the book (the mythical man month) a precursor to the agile movement?

others investigate the same: technion

Ideas from paper in [technion]: * not in year ‘75 but maybe ‘85 (approx)

The XP wiki page points to the C3 System: started in ‘93 and Kent Beck joined in ‘96

This other post: http://dhondtsayitsagile.blogspot.com/2010/01/mythical-man-month-by-frederick-brooks.html:

Though I found the book a bit dry and out of date, it was worth a quick read for the simple reason that it holds so many ideas that are so strongly advocated by Agile practices, and others that are not. Consistent with agile–we must use a process that assures us that “one always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build”; “conceptual integrity is the most important consideration in system design”. Communication is critical–and exponentially more difficult with larger and larger teams. He advocates giving developers room to be creative, saying they need room for “invention and craftsmanship” […]

He also believes in “done-done”, in other words–“milestones musbe be concrete, specific, measureable…coding, for counterexample, is ‘90 percent finished’, for half the total coding time. Debugging is ‘99 percent complete’ most of the time…”. Though stand-up meetings weren’t called it at the time, he knew the wastes of “status-review” meetings, and started calling things problem-action meetings instead

XP values: * http://www.extremeprogramming.org/values.html * http://www.softwarereality.com/lifecycle/xp/four_values.jsp

Hello World!

comments powered by Disqus