Is emergent design possible? (I think it is!)

Just the other day I had a discussion with a really experienced lead developer about the feasibility of the no-big-design-up-front-approach and the necessary circumstances to make emergent design work.

Along comes these series of articles from Abby Fichtner that I stumbled upon last night.

And although there's more to emergent design than Bob Martins SOLID principles I think these articles make an excellent starting point for a deeper discussion of the subject.

• SOLID Code with Emergent Design - Part 1
• SOLID Code with Emergent Design - Gimme an S
• SOLID Code with Emergent Design - O, I get it
• SOLID Code with Emergent Design - The L
• SOLID Code with Emergent Design - The Other ISP
• SOLID Code with Emergent Design - The Final Chapter

Cheerio

MM

Something completely different - Software I'd really love to buy...

...if it only existed...

(Mac mandatory of course)

• A word processor that really separates style and content - and still has a wysiwyg interface.
• A content managements system that does the same - minus the wysiwyg and plus a clear separation between content management (code) and delivery (from a pure static server, as they are available as commodity nowadays)
• Access done right -
  
  1. For the Mac
  2. For different backends (mySQL, posgreSQL, SQLite, ...)
  3. Less Wizards - more ER-Modelling
  4. Keep the grid view, the forms and (especially) the reports
• A stand-alone, sql-based, cross report generator with pdf (and perhaps rtf) as target format
• A format translator for Text-Files for all the different formats people want out there. Just feed in the Markdown, MultiMarkdown or Asciidoc Styles on one side, match them up with the respective publishers Word, LaTex or openOffice styles and ... presto - your final draft comes out

... wanted to do all of these myself ... never found the time (of course) ... so, if anybody out there is just looking for a cool idea for her next project - feel free to implement any or all of the above...

Cheerio

Michael

Oh, and BTW: I'd volunteer as beta tester...

How many Backlogs do you need?

Hmm... there used to be two backlogs in scrum IIRC:
the product backlog, owned by the Product Owner and the sprint backlog owned by the team.

Nowadays, scanning through contemporary tweets and blog entries, there are at least (in various amounts)

• Product Backlog
• Sprint Backlog
• Impediment Backlog
• Technical Debt Backlog

So I wondered: Do we really need them?
Right now my answer would be "Yes" and actually I think most of us use them already - albeit more or less secluded.

Of course the Product Backlog and the Sprint Backlog are completely visible all the time.

The Impediment Backlog and the Technical Debt Backlog OTOH are not quite as popular - mostly because we "should not have them" in the first place. If all "impediments are resolved within 24 hours" and "technical debt is paid back before a task is completed (aka Done)" and we "leave everything cleaner than we found it" both "Backlogs" are more like personal lists with a lifespan of less than a day.

Unfortunately reality is slightly different in lots of places and so we should recognize this fact and install corresponding backlogs with a fitting set of attributes.

So, what could these attributes be?

For the Impediment Backlog I'll try:

The usual stuff:

• ID (Yes, I need an ID - but YMMV )
• Synopsis (An understandable but very short description of the impediment that can be scribbled during the standup meeting )
• Description (A longer description, that explains the impediment to the non-initiated)
• Date created (well...)

The specific stuff for the impediment backlog:
(All of these should be considered optional and used as growing lists - just to make sure the impediment gets the attention it deserves)

• Number of Mentions (A counter - implemented e.g. as a tally chart on index cards - to determine if the impediment is really such an impediment as it first seemed)
• People affected
• Tasks affected
• Stories affected
• area(s) affected (e.g. Specs, Tests, Coding, Deployment, Design etc.)

For the Technical Debt Backlog I'll go with…

The usual stuff (what did you expect?):

• ID (Yes, I still need an ID - but YMMV still )
• Synopsis (An understandable but very short description of the dept imposed than can be scribbled during coding or the standup meeting without much of an interruption)
• Description (A longer description, that explains the debt and its effects to the non-initiated, probably written later)
• Date created (well...)

The specific stuff for the technical debt backlog:

• Area affected (e.g. Architecture, Design, Delivery, Deployment, Stability etc.)

Hmm.. that's not so much - I wonder if the list will grow over time.
I'd expect some of the TDB (technical debt backlog) to turn into tasks eventually, but they might also vanish simply because of DoD (definition of done), "no broken windows", "leave everything cleaner than we found it" and other related practices.
I wonder if it would be possible to derive the interest rate of technical debt... but that's quite another story.

Continuous integration in the German blog

Did I mention my new article on continuous integration in the german blog?

You can find it at shu-ha-ri (never mind the typo in the url - I somehow lost a n and an u when entering the title and since cool uris don't change - according to w3c - I decided to keep it like that for now)

Cheers
Michael

Get it in writing

I repeat this lecture ever so often.
Whenever possible "Get It in Writing" - not only to have proof of agreements but even more to make sure that both parties have the same understanding of them.
And sometimes it also provedes the means to make sure that you and the person you're talking with have the same understanding of implicit assumptions.
The most compelling story to back this was told to by a tour guide in New York when we drove along 42nd street.

When William Van Alen was hired to construct New York's Chrysler Building he was so sure of himself - the tour guide told us - and so well versed in the trades of the craft that he didn't bother to get a written contract. After all 5% of the buildings overall building cost was a well established fee in the market
After the building was completed - beating the Bank of Manhattan in the race for tallest building of the world - Chrysler refused to pay Van Alen with words like: "We don't have a contract. You should take more care to always get it in writing". Of course I don't know if this is a true story or not, but at least it serves well to remind me of my own advice.

OTOH it's hard to capture everything beforehand and some thing are so engrained into our perception of the world that I also tend to put more trust in the co-operation than I should.

Cheers
_MM_
(BTW: The story itself is of course backed - at least somehow, although with slightly different numbers - by wikipedia in the last paragraph about William Van Alen's Life)