You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.
(Wish I had thought about that two weeks ago)
Tuesday, January 11, 2011
Notes to self 006 - Be aware of the focus of the reciepient
In an oversimplified view there are generalists (often sporting an NT of NF in MBTI speak) and there are "detailists" (often sporting an SP or SJ in MBTI speak).
You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.
You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.
Monday, January 10, 2011
Notes to self - 005, Get it in writing - even if you have to put it there yourself
As I wrote a while back it is always a good idea to get important agreements in writing - Today I just had to remind myself that - especially in these days of electronic communication - there is always the option to put it writing yourself.
As a last resort - e.g. if an official protocol would be taken as an offense - I take the tangential approach as in "When we agreed on we also mentioned - would it be OK for you to treat these separately?" thus getting a written - and circulated - record of without offending my negotiation partner.
I most cases though it should be quite OK just to communicate openly and agree on putting the agreements in writing just to make sure that there are no misunderstandings.
As a last resort - e.g. if an official protocol would be taken as an offense - I take the tangential approach as in "When we agreed on
I most cases though it should be quite OK just to communicate openly and agree on putting the agreements in writing just to make sure that there are no misunderstandings.
Wednesday, January 05, 2011
Notes to self - 004, Keep local backups - The Cloud might dissolve
Keep local backups - The Cloud (aka the web) might dissolve locally
Just now a wiki that was on my list of important resources (the former wiki of the AYE conference) vanished with no clue about it's future.
It not only sadden's me because Cool URIs don't change but also because there was a lot of content even at the simple members pages, that I didn't bother to make a copy of.
The saddest thing is that it would have been easy for me to make a local copy of the wiki - after all, that is what tools like SiteSucker are for, right?
I just have to use them more often...
Therefore this very serious note to self: Keep local backups!
====8<------ End of Note to self
Comment to self:
Now the last resort for this case is the Way Back Machine, but that of course doesn't always have snapshots that include all I want to retrieve.
Just now a wiki that was on my list of important resources (the former wiki of the AYE conference) vanished with no clue about it's future.
It not only sadden's me because Cool URIs don't change but also because there was a lot of content even at the simple members pages, that I didn't bother to make a copy of.
The saddest thing is that it would have been easy for me to make a local copy of the wiki - after all, that is what tools like SiteSucker are for, right?
I just have to use them more often...
Therefore this very serious note to self: Keep local backups!
====8<------ End of Note to self
Comment to self:
Now the last resort for this case is the Way Back Machine, but that of course doesn't always have snapshots that include all I want to retrieve.
Notes to self - 003, Write each email as if it will reach your worst enemy
=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----
Write each email as if it will reach your worst enemy because the chances are - it will!
Email might look like instant messaging or conventional mail - depending upon your background - but it isn't.
While it's not very common for IMs to get copied and pasted (although it happens) and conventional mails are only forwarded for a fee it is common practice to just press "forward" on an email. Considering that you might want to re-consider the idea to vent in an e-mail like "Hey Adam, I can't get Bob to do [whatever] - he's just to stupid and ignorant. Please do something about it".
Chances are that Adam just presses forward, adds "Bob, please do [whatever]!" and sends it directly to Bob.
If Bob wasn't your worst enemy before he probably won't be after - but I think the chances are high that your relationship with Bob won't exactly get better after this exchange.
As usual YMMV. I just had to remind myself about that yesterday. Again. (But at least I caught myself in time.)
=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----
Write each email as if it will reach your worst enemy because the chances are - it will!
Email might look like instant messaging or conventional mail - depending upon your background - but it isn't.
While it's not very common for IMs to get copied and pasted (although it happens) and conventional mails are only forwarded for a fee it is common practice to just press "forward" on an email. Considering that you might want to re-consider the idea to vent in an e-mail like "Hey Adam, I can't get Bob to do [whatever] - he's just to stupid and ignorant. Please do something about it".
Chances are that Adam just presses forward, adds "Bob, please do [whatever]!" and sends it directly to Bob.
If Bob wasn't your worst enemy before he probably won't be after - but I think the chances are high that your relationship with Bob won't exactly get better after this exchange.
As usual YMMV. I just had to remind myself about that yesterday. Again. (But at least I caught myself in time.)
=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----
Tuesday, January 04, 2011
Notes to self - 002, Keep Records! Measurement & Calculation beats guesswork
=====8<---------- Start of note-to-self 002, Keep Records! Measurement & calculation beats guesswork ----
Sometimes I have to reminded myself to "eat my own dogfood" (or "take my own prescriptions")
Why should I not apply the same principles to facilitation that I recommend for software development?
Yesterday's Weather is perfectly applicable to meeting facilitation - if you know your tasks.
It's rather a high probability that the same task with the same amount of people in a retrospective (e.g. gathering data via a FrIm Chart) will take more or less the same amount of time.
So - to develop a plausible agenda - it's helpful to record the time each task took and the relevant circumstances (Time of day, number of participants etc.)
Therefore: Keep Records!
In the case of retrospectives you get a very sound foundation base your planning on data instead of guesswork very quickly. I'd say 3 Iterations should gauge your instruments [for that team] pretty precisely.
=====8<---------- Start of note-to-self 002, Keep Records! Measurement & Calculation beats guesswork ----
Sometimes I have to reminded myself to "eat my own dogfood" (or "take my own prescriptions")
Why should I not apply the same principles to facilitation that I recommend for software development?
Yesterday's Weather is perfectly applicable to meeting facilitation - if you know your tasks.
It's rather a high probability that the same task with the same amount of people in a retrospective (e.g. gathering data via a FrIm Chart) will take more or less the same amount of time.
So - to develop a plausible agenda - it's helpful to record the time each task took and the relevant circumstances (Time of day, number of participants etc.)
Therefore: Keep Records!
In the case of retrospectives you get a very sound foundation base your planning on data instead of guesswork very quickly. I'd say 3 Iterations should gauge your instruments [for that team] pretty precisely.
=====8<---------- Start of note-to-self 002, Keep Records! Measurement & Calculation beats guesswork ----
Sunday, January 02, 2011
Notes to self - 001, Always put up a visible agenda
Each working day I learn something new - or relearn something old.
=====8<---------- Start of note-to-self 001, Always put up a visible agenda ----
Today I recalled a lesson from AYE - When facilitating a meeting with different personality types it helps everybody to set up a visible agenda and adhere to it - as log as it leaves enough room for deviation.
Some people need a clear picture of where the discussion is going while others are comfortable by "going with the flow". While it doesn't do harm for the latter if you put up an agenda - as long as the topics are liberal enough - it enables those who are in favor of the clear picture to focus on the topic at hand without worrying to much about what might come next.
The fact that the agenda might be helpful for the facilitator as well might be noteworthy as well - for example as a tool to direct the focus or as a tool to postpone the discussion to a later topic. Mixes well with a 'parking lot' to keep track of topics/issues to cover. But of course YMMV
[And of course "Always" should always be used with caution - in this case it is
meant to be read as "Whenever it is applicable, use common sense"]
=====8<---------- End of note-to-self 001, Always put up a visible agenda ----
What are these notes-to-self?
As Alan Weiß' calculation "if one improves 1 percent a day, one will be twice as 'good' in 70 days" shows the possibilities for self improvement are enourmous. (according to Kn = K0 * (1 + (p/100))^n => 1 * ( 1 + (1/100))^70 => 1.01 ^ 70 => 2.0067633... it is even a little bit more...)
But in my experience that math doesn't compute - or at least not for me.
Although I do work on getting better every day there also is a constant loss going on with me. I forget things, I don't apply learnings to new situations, I fail in the application some piece of knowledge that I posses and so on.
When (and if) I realize these events I have a chance to get my 1 percent for that day. (Nah - not really - make it 0.1%)
Up until now I tried to make a "mental note" of these learnings - both old and new. But after only one year it's hard for me to go over 365 purely mental notes, so I thought I should explicitly put them somewhere.
Starting today I'll try to pick the most important one of these aha-effects for each working day (no correlation to business days - I work freelancing) and put it down here. Each note-to-self will consist of the note itself plus a short explanation of it's meaning and context, as can be seen above in the first one.
Topics might be from a very wide range - don't expect notes on CxO level if I spent the day knee deep in code. I guess I'll cover:
=====8<---------- Start of note-to-self 001, Always put up a visible agenda ----
Today I recalled a lesson from AYE - When facilitating a meeting with different personality types it helps everybody to set up a visible agenda and adhere to it - as log as it leaves enough room for deviation.
Some people need a clear picture of where the discussion is going while others are comfortable by "going with the flow". While it doesn't do harm for the latter if you put up an agenda - as long as the topics are liberal enough - it enables those who are in favor of the clear picture to focus on the topic at hand without worrying to much about what might come next.
The fact that the agenda might be helpful for the facilitator as well might be noteworthy as well - for example as a tool to direct the focus or as a tool to postpone the discussion to a later topic. Mixes well with a 'parking lot' to keep track of topics/issues to cover. But of course YMMV
[And of course "Always" should always be used with caution - in this case it is
meant to be read as "Whenever it is applicable, use common sense"]
=====8<---------- End of note-to-self 001, Always put up a visible agenda ----
What are these notes-to-self?
As Alan Weiß' calculation "if one improves 1 percent a day, one will be twice as 'good' in 70 days" shows the possibilities for self improvement are enourmous. (according to Kn = K0 * (1 + (p/100))^n => 1 * ( 1 + (1/100))^70 => 1.01 ^ 70 => 2.0067633... it is even a little bit more...)
But in my experience that math doesn't compute - or at least not for me.
Although I do work on getting better every day there also is a constant loss going on with me. I forget things, I don't apply learnings to new situations, I fail in the application some piece of knowledge that I posses and so on.
When (and if) I realize these events I have a chance to get my 1 percent for that day. (Nah - not really - make it 0.1%)
Up until now I tried to make a "mental note" of these learnings - both old and new. But after only one year it's hard for me to go over 365 purely mental notes, so I thought I should explicitly put them somewhere.
Starting today I'll try to pick the most important one of these aha-effects for each working day (no correlation to business days - I work freelancing) and put it down here. Each note-to-self will consist of the note itself plus a short explanation of it's meaning and context, as can be seen above in the first one.
Topics might be from a very wide range - don't expect notes on CxO level if I spent the day knee deep in code. I guess I'll cover:
- very low level (like: Note to self: ci
in vim is important or Note to self: make sure you're laptop is in powersave if you give a presentation in an hour) - development related (like: rvm helps with the descendants of the dll hell)
- coaching related (Note to self: What looks like resistance is often lack of safety)
- Facilitation related (see above)
Or something that I haven't yet thought of.
Thursday, June 24, 2010
Estimate - 'an' or 'to'?
A couple of days ago I got into quite an interesting discussion [cited below] with David J. Anderson (http://www.agilemanagement.net) on Twitter about the need (or not) of estimates in Kanban.
From what I learned 'estimate' has quite a different notion in my book than in his. Considering the fact that with me 'in my book' is only a manner of speaking while David actually 'wrote the book' (on Kanban in software development that is) I thought it would be a good idea to question our differences a little more thoroughly.
The initial difference is the statement, that in Kanban there are no estimates (missing source, perhaps misquoted) while on the other hand (as Olaf Lewitz noted [see below]) in the definition of service classes (on pg. 131 to be exact) David states "No estimation is performed..." but "Standard class items may be analyzed for size. Large items may be broken down into smaller items.".
Two things are notable here for me - the first one is, that I filtered out the second half of the first sentence. What he really says is "No estimation is performed to determine a level of effort or flow time."
The second one is my reaction to the idea of "No estimation but analysis".
For me it is very important to tell people, that you don't have to know the exact size/effort/duration of a task but that it's OK to estimate. So the point for me is 'to estimate' is important to get over the negotiation phase and to avoid getting stuck in analysis paralysis. From what I read from one of Davids tweets I gather that for him it's important that the analysis of a class item should not contain any assumptions about how long it will take and when the item could/should be delivered. (On the other hand I could off course also have a complete misunderstanding of his intentions...)
So now it seems:
'to estimate' => good from my point of view because it frees from BDUF risk
'an estimate' => not so good from Davids point of view because it implies known effort and delivery date
But on a related note David wrote:
"so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation"
As much as I can relate to that point of view I still have a great problem with the wording because ever so often when some (not all) developers hear/read that they don't have to estimate any longer if method/process is applied they interpret that as 'now I can just code and don't have to make any commitments beforehand'.
So, even when applying Kanban I would still like my teams to have the freedom to give estimates on item sizes - especially on big ones. And even on small item I would alway want a way to include a "give or take" to any number that's being passed around. And for me this leeway is what differentiates an analysis based on exact calculations from a plan that is based on estimations.
So David, should you read this (as I hope you will) - is our difference just a question of wording (English is still a foreign language to me) or is there really a fundamental difference in our position?
Just for the record: the original Twitter threads:
Thread 1:
(ended at msg. id:16427657813)
agilemanager says:
@MMahlberg "'too large' is an estimate" only in the most degenerate of senses. It is not something you can plan or commit from
MMahlberg says:
@agilemanager analysis!=estimation: ok, estimation!=decomposition: ok, but decomposition involves estimation (e.g. 'too large' is estimate)
agilemanager says:
@MMahlberg for me estimation involves a time and a delivery date. it's not decomposition. analysis is not estimation
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
Thread 2:
(ended at msg. id: 16426940354)
agilemanager says:
@MMahlberg so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation. is this clearer?
MMahlberg says:
@agilemanager agreed: UML != estimation (notation/language vs. activity)
agilemanager says:
@MMahlberg for example you would never describe UML as an estimation technique
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
From what I learned 'estimate' has quite a different notion in my book than in his. Considering the fact that with me 'in my book' is only a manner of speaking while David actually 'wrote the book' (on Kanban in software development that is) I thought it would be a good idea to question our differences a little more thoroughly.
The initial difference is the statement, that in Kanban there are no estimates (missing source, perhaps misquoted) while on the other hand (as Olaf Lewitz noted [see below]) in the definition of service classes (on pg. 131 to be exact) David states "No estimation is performed..." but "Standard class items may be analyzed for size. Large items may be broken down into smaller items.".
Two things are notable here for me - the first one is, that I filtered out the second half of the first sentence. What he really says is "No estimation is performed to determine a level of effort or flow time."
The second one is my reaction to the idea of "No estimation but analysis".
For me it is very important to tell people, that you don't have to know the exact size/effort/duration of a task but that it's OK to estimate. So the point for me is 'to estimate' is important to get over the negotiation phase and to avoid getting stuck in analysis paralysis. From what I read from one of Davids tweets I gather that for him it's important that the analysis of a class item should not contain any assumptions about how long it will take and when the item could/should be delivered. (On the other hand I could off course also have a complete misunderstanding of his intentions...)
So now it seems:
'to estimate' => good from my point of view because it frees from BDUF risk
'an estimate' => not so good from Davids point of view because it implies known effort and delivery date
But on a related note David wrote:
"so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation"
As much as I can relate to that point of view I still have a great problem with the wording because ever so often when some (not all) developers hear/read that they don't have to estimate any longer if method/process
So, even when applying Kanban I would still like my teams to have the freedom to give estimates on item sizes - especially on big ones. And even on small item I would alway want a way to include a "give or take" to any number that's being passed around. And for me this leeway is what differentiates an analysis based on exact calculations from a plan that is based on estimations.
So David, should you read this (as I hope you will) - is our difference just a question of wording (English is still a foreign language to me) or is there really a fundamental difference in our position?
Just for the record: the original Twitter threads:
Thread 1:
(ended at msg. id:16427657813)
agilemanager says:
@MMahlberg "'too large' is an estimate" only in the most degenerate of senses. It is not something you can plan or commit from
MMahlberg says:
@agilemanager analysis!=estimation: ok, estimation!=decomposition: ok, but decomposition involves estimation (e.g. 'too large' is estimate)
agilemanager says:
@MMahlberg for me estimation involves a time and a delivery date. it's not decomposition. analysis is not estimation
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
Thread 2:
(ended at msg. id: 16426940354)
agilemanager says:
@MMahlberg so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation. is this clearer?
MMahlberg says:
@agilemanager agreed: UML != estimation (notation/language vs. activity)
agilemanager says:
@MMahlberg for example you would never describe UML as an estimation technique
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
Wednesday, September 30, 2009
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
Sunday, September 20, 2009
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 -
- For the Mac
- For different backends (mySQL, posgreSQL, SQLite, ...)
- Less Wizards - more ER-Modelling
- 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
Cheerio
Michael
Oh, and BTW: I'd volunteer as beta tester...
Sunday, August 23, 2009
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.
Wednesday, August 05, 2009
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
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
Thursday, April 02, 2009
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)
Monday, September 29, 2008
scm & build: Levels of configuration
Here's the first little part of the (to be - or not -) series on configuration management and build management.
Although I wanted to start with some clarification on "Task level commits" I actually concentrated on different levels of configuration in a build environment. Here we go...
Basically – unless the application-to-be is monolithic – there are four levels of abstraction: Machine dependent, user dependent, purpose dependent and (last but not least) project specific configurations. Each of this has to be managed separately and consciously to avoid (to much) manual intervention. Talking about indirection let me cite (once again) David Wheeler to whom the phrase “Any problem in computer science can be solved with another layer of indirection. ” is attributed. As he stated in the second part – which is often omitted – “[But] this usually leads to another problem” so let's have a look at the relative pros and cons of this fine distinction. To start of lets examine each level a bit closer.
And of course there are some things (e.g. logging) that need to be configured differently for each of these levels. But speaking of logging we encounter another type of configuration that should not be mixed with the purpose specific configuration: the project specific configuration of components. While I'll go deeper into those in the next paragraph, the important part with respect to things like logging is to be aware of the fact that some thing have both – a project specific configuration and a purpose specific one. Trying to manage both in the same way can create real nightmares (I guess, everybody who has tried to keep Log4J configuration files useful for an extended period of time without that conceptual distinction knows what I'm talking about)
Although these configurations are applicable on many levels – from configuration information specifying a windows' layout to the much mentioned log-file configurations – at least they have a clear association. They are “just another kind of source code” and thus relatively easy to handle.
To summarize: We have the purpose specific configuration which is a central [[build]] topic, the project dependent configuration that correlates to source code, the machine dependent configuration that correlates to hardware configuration management, and the user specific configuration that somehow correlates to profile information. All of these should have traceable connections to identify possible configuration errors.
After I have raised all these questions of course I should also answer them – I'll do so some time in the future and will provide a follow-up link in this post...
I think that even the concept to have different levels of configuration enables people to create more stable build environments.
Cheers
_MM_
Although I wanted to start with some clarification on "Task level commits" I actually concentrated on different levels of configuration in a build environment. Here we go...
The levels of configuration
One of the biggest differentiators between a one-man-show and a team-effort-project are the different levels of configuration that have to be managed – and this is also a point where the quality of the whole build process can be heavily influenced.Basically – unless the application-to-be is monolithic – there are four levels of abstraction: Machine dependent, user dependent, purpose dependent and (last but not least) project specific configurations. Each of this has to be managed separately and consciously to avoid (to much) manual intervention. Talking about indirection let me cite (once again) David Wheeler to whom the phrase “Any problem in computer science can be solved with another layer of indirection. ” is attributed. As he stated in the second part – which is often omitted – “[But] this usually leads to another problem” so let's have a look at the relative pros and cons of this fine distinction. To start of lets examine each level a bit closer.
Remarks:
By the way: Of course there are at least two Dimensions involved in this topic as well: run-time configuration and build time configuration. For the sake of this argument I'll postpone this discussion towards the [[build]] topic.Purpose dependent configuration
Let's start with the purpose dependent configuration since this is a concern covered in most modern environments. The purpose I'm talking about is also known as build type or target environment or something similar to that. Typical purposes are “Test”, “Debug”, “Release” or – a bit less frequent – “Integration”. Depending on the purpose of the build there usually are a number of things that differ. For “Test” there might be some hard-wired shortcut to circumvent server-roundtrips or a “don't really send to printer”-entry or some other special behaviour that is meant to make testing easier (or even possible) without imposing side-effects on already installed systems. If you're building for “Debug” – one of the most commonly differentiated purposes – you'll certainly want to include debug information into your code, something you probably don't want to ship (although that could be disputed, but that is another story). “Release” of course is the purpose with which you build the shippable product once all test and QA-work has been done. The necessity of an “Integration” purpose arises only in projects where you need to integrate several sub-products and usually has rather project-specific configuration needs.And of course there are some things (e.g. logging) that need to be configured differently for each of these levels. But speaking of logging we encounter another type of configuration that should not be mixed with the purpose specific configuration: the project specific configuration of components. While I'll go deeper into those in the next paragraph, the important part with respect to things like logging is to be aware of the fact that some thing have both – a project specific configuration and a purpose specific one. Trying to manage both in the same way can create real nightmares (I guess, everybody who has tried to keep Log4J configuration files useful for an extended period of time without that conceptual distinction knows what I'm talking about)
Project specific configuration
This usually is the first configuration option you come across. Almost any project nowadays uses some reusable libraries. Those of course have to be adapted to the specific needs of the project and thus the first level of configuration indirection comes into existence.Although these configurations are applicable on many levels – from configuration information specifying a windows' layout to the much mentioned log-file configurations – at least they have a clear association. They are “just another kind of source code” and thus relatively easy to handle.
Machine dependent configuration
This one strikes as soon as there is even one more developer! The path which used to point at /usr/bin has to point to /usr/local/bin, the drive for intermediates that used to be C: has to be E: and the monitor resolution goes from 1024x768 to 1600x1050. Consequently some things have to be configured somehow – and here we definitely need a distinction between build-time and run-time.User dependent configuration
The distinction between user dependent configuration and machine dependent configuration is a bit hard to make in a time where the correlation of people:machine moved from n:1 to 1:n. But even now – where lot's of people have more than one computer the real relationship is more like n:m since some computers are still shared. Especially build and integration machines are prone to sharing. Now, even on the same machine, the configuration might differ in paths, desired screen resolutions and mounted network shares, so there is basically the same set of configuration information as there is in the machine dependent part, but it needs to be managed in a separate space.To summarize: We have the purpose specific configuration which is a central [[build]] topic, the project dependent configuration that correlates to source code, the machine dependent configuration that correlates to hardware configuration management, and the user specific configuration that somehow correlates to profile information. All of these should have traceable connections to identify possible configuration errors.
After I have raised all these questions of course I should also answer them – I'll do so some time in the future and will provide a follow-up link in this post...
I think that even the concept to have different levels of configuration enables people to create more stable build environments.
Cheers
_MM_
Thursday, September 18, 2008
Best Practices - like everybody does it?
In a recent Dilbert comic strip the much cited protagonist replies to his boss: "If everybody is doing it, Best Practices is the same thing as mediocre"
Made me think...
_MM_
Made me think...
_MM_
Monday, September 15, 2008
Build-, Version-, Configuration- and Sourcecodemanagement,
Lately I found myself talking about buildmanagement and configuration management a lot. And since this blog lies deserted in the wild anyway I think this is the perfect place to ramble about that stuff so I can point other at some more ressources than I can right now. (And of course other can point me to my own ramblings if I get lost in the discussion)
Topics I’d like to discuss (although this probably wont ever come to an end) include simple, practical, down to earth things like
Stay tuned for the first episode in about a week (and nudge me if I havent published it in two weeks!)
Cheers
_MM_
Topics I’d like to discuss (although this probably wont ever come to an end) include simple, practical, down to earth things like
- The simplest way to set up svn to work with xcode for a small workgroup
- How to set up (any) DVCS for XCode
- How does SCM-integration work in XCode
- Command line builds
- To branch or not to branch
- Releases, Versions, Variants and other “Numbers”
- What is Multi-Dimensional SCM
- Staging and promoting
Stay tuned for the first episode in about a week (and nudge me if I havent published it in two weeks!)
Cheers
_MM_
Subscribe to:
Posts (Atom)