agile aspects

The "Last Responsible Moment" may be sooner than you think

2012-01-30T16:47:00.008+01:00

Now that was a nice one - as a practitioner of agile 'stuff' I have been a big fan of postoponing decisions to the last responsible moment for quite a while.
Suits my way of looking at things too.
The question of course is: When exactly is the last responsible moment? Usually when building software it is tempting to work with the assumption that the last responsible moment is right before I write the line of code related to the decision. Works well with the way 'agilistas' despise Big Design Up Front too.

Funny when you start to compare software development with the real life. (After all: That's what object orientation is all about, right? Modelling the real word with software representations? But let's take that at another time and come back to the subject at hand.
While I literary roamed the world in 2011 the concept of planning with regard to the "Last Responsible Moment" made the rounds on some of the mailing lists concerned with agile software development practices.
I on the other hand tried to live a 'normal life'. writing software and preparing material during the daytime, while spending the evenings with everyday pasttimes - in my case Aikido. Never mind if you have never heard of Aikido - although you might want to look it up at Wikipedia.

The question in case is the one of the latest responsible moment - in this case the moment for the decision on whether to hitch a ride with one of my fellow aikidoka, take a cab or take the bus.

To cut a long story short - in the real world the latest responsible moment is not when you reach a bus stop a couple of miles of the central public transport axis of dubai, shortly after your last training buddy has left.
Especially if the area temporarily has no cell phone reception and that particular bus stop is only serviced until half an hour earlier at this time of the year (mentioned in the small print)

16 elevator pitches for scrum as a contribution to @boeffi's compilation

2011-08-11T05:08:00.014+02:00

As an answer to a recent query for scrum elevator pitches on twitter from @boeffi (Who also runs German blog on software development) I asked myself (and him subsequently) a couple of questions regarding the setting and desired result to target the 140 character accordingly...
Unfortunately (for me) his answer was "All of them".
Please join the discussion at his site

Challenge accepted!

Given that I asked about four dimensions I think 16 "pitches" of less-than-140 characters will do for starters...

The collection of Scrum Elevator Pitches

Please read the disclaimer below - don't use them literally

The physically realized earned value from delivering fully functional slices in scrum takes ROI from estimatable to measurable
MSLM: Management, Sell, Long term, Money
Proccesses like Scrum can help in the transformation of the whole organization towards lean by providing transparency throughout.
MCLM: Management, Convince, Long term, Money
By concentrating on the most valuable parts in shippable slices Scrum reduces time to market considerably - often to a few weeks.
PSLM: Users, Sell, Long term, Money
Instead of investing the subject matter expert's time in the test at the end Scrum involves him early to build a fitting product
PCLM: User, Convince, Long term, Money
One scrum project, budgeted for 10 Mio $ was ended after spending only 2 Mio $ – because it had delivered all the important features
MSSM: Management, Sell, Short term, Money
Scrum's focus on a "potetially shippable" increments ensures that the produced product-parts provide real value to the users
MCSM: Management, Convince, Short term, Money
The proven prioritization models of Scrum enable you to get high value from the development team early for your time investment
PSSM: User, Sell, Short term, Money
The continuous effort you put into specifications can be turned into continuously valuable and tangible results by Scrum
PCSM: User, Convince, Short term, Money
Scrum can give organizations the information they need for a fundamental reorientation - or help to make them ready for it
MSLB: Management, Sell, Long-Term, Buy-in
Having crunch times and lulls can be countered by adopting the basic Scrum rules - they create a self balancing, sustainable system
MCLB: Management, Convince, Long-Term, Buy-in
Getting Scrum to both sides - developers and users - gives users a real strong lever over the scope of the final delivery
PSLB: User, Sell, Long-Term, Buy-in
If all the effort that goes into upfront specs went into a Scrum-like collaboration the results would be closer aligned to the needs
PCLB: User, Convince, Long-Term, Buy-in
Scrum is a set of techniques that generates transparency and makes projects predictable and controllable again.
MSSB: Management, Sell, Short term, Buy-in
With scrum both parties of product development lay out rules that ensure - but also requires - mutual commitment and engagement
MCSB: Management, Convince, Short term, Buy-in
With Scrum you get the opportunity to set the direction of the development at least once a month.
PSSB: User, Sell, Short term, Buy-in
If you want to gain a real and direct influence over the priorities in the development team you might want to have a look at scrum.
PCSB: User, Convince, Short term, Buy-in

Explanation of the Dimensions: Audience, Goal, Timeframe, Required Action
Audience: [Management=M, user representative or possible Product owner=P]
Goal: [Sell=S, Convince=C]
Timeframe: [Long term=L, Short term=S]
Required Action: [allocate Money or resources=M, Buy in=B]

Disclaimer

These are examples of pitches for generic situations - don't use them! Forge your own given your specific situation and requirements.
In my opinion there is no such thing as one right elevator pitch for anything - it's all about the context.

One Inbox or Inbox Zero?

2011-07-06T05:28:00.006+02:00

Since when does "Inbox Zero" refer to email?

When I first heard of the idea of an empty inbox it did not refer to you email inbox - instead it referred to a very physical inbox and to the management of workflows. Merlin Mann did an excellent Job of tying the inbox metaphor in the context of inbox zero to the email mailbox with his article series.

In GTD (getting things done) the inbox is something quite different

From what I understood from the GTD book by David Allen the point of an GTD-Inbox is twofold. First to get things out of your mind quickly and secondly to have one place of reference for your tasks/todos. Once you have that you can apply the two-minute-rule and other things from the GTD toolkit.
So actually in this model the inbox is a logical container for all the stuff you have to do.

Using the email inbox as a todo list harms your work organization

If my inbox is tied to the email system my work is tied to my computer. Assuming I wanted to set up a workflow system that is more pull oriented and does not necessarily contain only virtual to dos I would have to somehow bend your email workflow and it would be hard to use a different tool for your workflow management. Although I have to admit that there was a time when I had email folders called "Pending", "In Progress", "Waiting" and "Done" - but they didn't have WIP-Limits and it was at a time before David Anderson had even begun to write the Software Kanban Book.

Goals of the Inbox

Having one place to collect all todos is far more important for me than having an empty "unsorted pile" - which basically is what the "inbox" really is.

"Email Inbox Zero" is quite random IMO

Why the heck are so many people possessed with getting their (email) inbox to zero? What about their Twitter Inboxes, their Skype Inboxes their paper inboxes, their... you get the picture. So instead of trying to achieve inbox Zero I just scan my emails whenever they arrive or I have the time to do it. If I think I have to act upon one of them I create a ToDo in a secondary system. If I need to reply, i create an empty response, save that (so that don't have to search for the original) and create a ToDo in a secondary system.
The todos in this secondary system are completely independent from my mail workflow, my inbox contains literally tens of thousands of emails and I don't have any problem with that.
And I don't spend hours of thinking about ways to find an effective way to abuse my email system.

Plain text is king? Pen and Paper?

So what magical secondary system do I use?
None at all.
Right now I work with a three tiered approach consisting of Pen and Paper for the first tier, and two documents in plain text that get synchronized between all my devices.
I guess everybody has to find their own solutions. But that is not the point. The point is: It is not you E-Mail inbox and copying, deleting or moving hundreds of emails per day might even eat up time that you could spend getting things done.

Cheers
Michael

(This post is v0.9 but the ship date has arrived...)

Pre-flight checks are possible on planes but not on Enterprise Applications - why?

2011-05-26T23:49:00.021+02:00

Unit testing is all pretty well but what about delivering these tests into production?
Is it a good idea? Or is it "nice for toy applications, but you can't do that with Enterprise Applications, because there is to much money/security/personal data at stake"?
And what kind of tests are we talking about anyway?

Basically this post is meant to debunk some believes that I encountered during a couple of Enterprise Application projects. Lets look at them:

We write throw-away code for unit tests that that we wouldn't need if we didn't write unit tests

[The] tests are only usefull during development - they /must/ be removed from production code

We don't need to simulate the connected systems once we get the real systems connected

Throw-away code is effort that's useless and could/should be avoided

While these claims seem very convincing at first sight and might be very appealing to managers who try to get a development team to be "more productive" their physical world counterparts tell that story quite differently. And my own - albeit to some extent seemingly counterintuitive - observation is that these believes seem to be quite wrong.

Now - if you're still with me (or against me - as long as you care about the matter) - let's debunk them one at a time

(Unit-) Tests require otherwise useless code - I don't think so!

Of course you need to write some things to automate the tests that would not be necessary if you did something else instead. Like testing the application manually. But that doesn't mean that you win anything by not writing "those things" in the first place. You'd just replace a checkable, repeatable way to test your program by one that’s dependent on the alertness of the tester (in fact: your alertness!), her or his mood, interruptions etc.

And let’s look at "those things" that you have to write. For me, three things come to mind - the tests themselves, some kind of test harness and some special diagnostic extension point where it is possible for the tests to get access (read and write) to otherwise unexposed information. I'll come back to the exposition of otherwise unaccessible information in the next section but the other two can be dealt with right away.

The tests themselves? Well, of course I could just test the System manually. But even if I was willing to re-test all possibly affected portions of my system each time I change my code - which I am not - it soon would become economically unsound. Apart from the sheer amount of time spent doing that, for any system that has reached a substantial size I would have to keep records of the test so that I can repeat them easily and know which parts have been retested since the last change and which still need some love. Just writing the tests is way less effort than the combined effort of writing specs, keeping track of the test I just did manually and the manual testing itself.

The test harness? I think this is addressed by the same consideration that hold true for the tests themselves. Plus the fact, that there often is no way to test without a test harness since the system under development relies heavily on surrounding components.

Test should be run only outside live systems - I don't think so!

So let's come back to those extra accessors we wrote for our test that are "only there for the tests". Well sometime they /are/ only there for the tests. Unfortunately. They could be so much more. Let's look at the real - sorry, physical - world for some comparison:

Airplanes and automobiles.
Have you ever wondered what all those dials on a typical airplane dashboard of the last century indicate? Well a lot of them show things that /should not be necessary to measure/ for example the exhaust gas temperature (egt). This also is a function of the manifold pressure and the fuel intake - both of which are displayed by other gauges. But measuring each of the components separately - which really is redundant if everything works as designed - gives the pilot the option to manually lean or enrich the fuel for optimal performance. And it serves as an indicator of possible related problems.

I still have to see an Enterprise Application where there is e.g. a counter for request, a counter for inserts and a counter for updates, that get monitored in production. Such counters usually are there - for the tests. And they are used - in the tests.
So why not take them to the production system?

Or take another element of pre flight checks (not applicable to jets), the mag-check. Usually airborne engines use a magneto based system for spark generation and two separate circuits with separate magnetos and two spark plugs per cylinder. The "normal operation" is to have both spark plugs running. But - and this is where Enterprise Applications differ hugely - the pilot can control this. Even in mid-flight. And it's part of the pre-flight check to test those unwanted conditions.

Like "Both" - Revs should be 1400, "Left" - Revs should drop (only one plug), "Both" - Revs should rise again, "Right" - … you get the picture.

But I've never seen something like that done to an Enterprise Application:
"Cache Available" => All pages should show in less than n milliseconds
"Cache not Available" => Pages x,y and z should show much slower
"Database available" => Data should be written to the database
"Database not available" => Data should be written to files

But wait - that's not possible.
Because we removed all the rods and knobs that enable direct access to those internals from the production code.

And more often than not it's not even possible to take the delivered application an debug it because the debug information - and even the symbol tables where applicable - have been removed. So it's necessary rebuild the production version including debug information from the source control and try to recreate the failing scenario.

If automobile engines where build like that you would have neither the yellow "general engine failure" light on the dashboard nor the option to go to the garage and have them plug in the diagnostics computer and tell you exactly that there are air bubbles in the fuel pipe every time the engine revs over 5521. (that's an example of course…)

Instead the garage would have to rebuild an engine exactly like the one you've got in your car and analyze the error from that one. Or at least completely disassemble your engine, insert probes, reassemble it and run it in an environment simulating your car.

Although there are numerous implementations where you can probe a running system - especially on Apples OS X - they are mostly aimed at system level functions or the core frameworks. Actually I think it's very sad that it is so uncommon for programs and especiall Enterprise Applications to reveal relevant information about their internals.

It's preferable to use The Real (connected) System for development - I don't think so!

Do you really think that, in the car supply industry, they fit each wiper motor in bodies of all targeted cars before they ship them? Last time I checked they used test rigs that have nothing in common with cars except for the interface to the wiper motor - but they might have some additional features like an instrument that measures the torque of the motor and another one that measures the current drain. And by mounting the wiper motor in that rig and measuring those values they can verify that it actually confirms to the contract to which both the car manufacturer and the supplier designed their part. (Which opens the road to Design by Contract - but that would be another story)

If you write code that get's deleted later than it's waste - I don't think so!

There are lots of examples from the ream world that tell a different story. The simple one of course is the paper cup you get with your coffee to go. It does get 'deleted' later on, when you throw it away, but I don't think it's feasible to do completely without it. At least I would either burn my fingers or at least ruin my shirt if I tried to take "only the coffee and nothing but the coffee" from my local takeaway. (Replacing the throw-away cup with a mug for multiple usage might be a good idea from an environmental point of view, but replacing it is not the same as "just don't do it”)

Another examples - that is perhaps more suitable from production point of view - is almost anything that has to do with casting metal. A wide range of casting techniques requires a cast that gets destroyed in the process. Those are made up of a multitude of materials and usually require serious work before the casting process can begin. And after the casting and cooling and hardening it often gets destroyed by brutal force - with hammers and pickaxes if needed. I really don't think you could build those metal things without the cast. So if I write code that for example simulates a calculation that will be build much later and gets thrown away once the more complex "real" function is implemented that - for me - is the mold that allows me to form the rest of my code around it.

References:
Theres a ton of related material out there, but "PPP" by Uncle Bob and the original edition of "Extreme Programming explained" by Kent Beck do a pretty good job of conveying the fundamental concepts. And throwing in some TDD by Kent Beck, BDD by Dan North plus Refactoring by Martin Fowler et. al. for good measure wouldn't do much harm either - but that's on my 2¢ and of course YMMV.

PPP = Agile Software Development, Principles, Patterns, and Practices by
Robert C. Martin
TDD = Test Driven Development: By Example by kent Beck
BDD = http://dannorth.net/introducing-bdd/
Refactoring = Refactoring: Improving the Design of Existing Code by Martin
Fowler, Kent Beck, John Brant and William Opdyke

Re: [Airbnb Community Support] Re: Airbnb.com iPhone Support Request

2011-04-28T17:52:00.002+02:00

Dear Airbnb, (CC'd to the same Blog as before)

please do me the courtesy of at least reading what I write.

Which part of "I don't want you to help me track the information down" did I write in such a way that it was so easily misunderstood?

Now I am not only a customer who feels that he is not in Control of his data but also a customer who infers from your actions that his concerns are of no real importance to you.

Yours, Michael

On 28 Apr 2011, at 17:07, Cathy H <notifications-support@airbnb.zendesk.com> wrote:

-- Please respond above this line. --

Cathy H, Apr-28 08:07 (PDT):
Michael,
Our records indicate that your reservation with Hannes in Vienna has been accepted. As payment you supplied us with a Mastercard ending in nnnn and were charged: $nnn / €nnn EU This charge was pushed through manually a moment ago, because when you entered your payment information you forgot to select the country you live in. We've done that for you and now you should see the charge on your credit card.
Your request with Eva in Vienna is no longer possible because she did not respond to your request within 24 hours. You were not charged for that.
Please let us know if we can provide further assistance.
Kind regards,
Cathy H
www.airbnb.com
855.4.AIRBNB (Toll Free) or 415.800.5959
Help Airbnb win a Webby Award, vote now! http://bit.ly/gpDDsW

Michael Mahlberg, Apr-28 07:14 (PDT):
Dear Airbnb, (CC'd to one of my blogs)
In the meantime the registration has expired and /after that/ the payment information is visible on the website - for a brief moment until I confirm the information. Then it's inaccessible again!
So, in the name of open Business-2-Customer relationships, here is what I would expect:
I don't want you to help me track the Information down - I want control over my data!
I want to be able to see /exactly/ which data you have on file for me.
I want to be able to see, which transactions are pending right now!
As much as I like the idea of your service, I don't feel comfortable if you play it so unreasonably close to the chest.
Cheers
Michael
( @MMahlberg on twitter )

Cathy H, Apr-28 06:57 (PDT):
Hi Michael,
We'd be happy to help you track this down. Can you please provide your reservation code?
Best,
Cathy H
www.airbnb.com
855.4.AIRBNB (Toll Free) or 415.800.5959
Help Airbnb win a Webby Award, vote now! http://bit.ly/gpDDsW

Michael Mahlberg, Apr-26 09:18 (PDT):
Please enter the details of your support inquiry below:

User Information
Name: Michael M.
ID: 533213
How can I find out, which of my credit cards I used to make a reservation?
Situation in case: 6 credit cards, one booking with airbnb - no movements on any account. Host has not yet (21 hours) responded.
Which c-card is on your files? which one can I max out?
Cheers Michael
User Information
Name: Michael M.
ID: 533213

(von unterwegs gesendet)

Airbnb Community Support
Phone: 1-855-4-AIRBNB | 415-800-5959
FAQ: www.airbnb.com/help

Why Google-Checkout sucks - at least for me

2011-04-18T10:16:00.009+02:00

I just tried to buy the electronic version of David J. Anderson's Kanban book, because I'm traveling the world quite a bit right now, left the paper book at home and wanted to look up a few specifics for the design my own personal kanban system.

Two things delayed my decision to buy it - and actually will delay it for a couple of days to come. Which is unbelievable for a process that takes a mere minute on amazon and the pragmatic bookshelf.

1) I have to buy the eBook twice to read it in iBooks and on the Kindle [see below]
2) I have to become a Google-Checkout Customer (which is the dealbreaker)

The Problems with Google-Checkout

They (Google Checkout) added my credit card info to the currently logged in google account
Really? The currently logged in account? That's just silly.
They (Google Checkout) stored the credit card information

Actually Amazon also stores the credit card data. But amazon is a store - Google is a search engine and an information broker. So I'm supposed to give my credit card information to an information broker, who adds new services to it's portfolio every day?
So, what I'll have to do now - to get the electronic version of a book I already own - is to get a prepaid credit card, put some money on it, connect that to google checkout, buy the book, disconnect the card from google-checkout.
[Aka: No, I don't want others to be able to control my credit card and identity management. That's where I really want a push system]
What a waste of time!

The Problem with buying the book twice

I use the Kindle for reading and the iPad for Browsing, and since the Kindle UI is only mediocre compared to iBooks I would love two have both formats available as it is possible with the pragmatic bookshelf. I admit that the Kindle UI is not as bad on the iPad as it is on the Kindle itself, but still it's a drawback compared to the iBook experience. So the current option for buying the book online isn't "quite" as pleasant as it would be to buy it from the pragmatic bookshelf - or perhaps I'm just spoiled by the latter's focus on customer value.

Note to self 15 - If a project has no risk - don't do it.

2011-03-17T19:50:00.004+01:00

Dear Michael,
Liz Keogh in her QCon London session on different kinds of incentives last week reminded me of this quote from Tom DeMarco and Timothy Lister's "Waltzing with bears".
As DeMarco and Lister put it in the book each and every project that is worth it's while has to have risk.
For me the implication of a project with "no risk" is not only, that it could be done by anyone in any environment but also that it doesn't matter if this project fails - essentially that is what "no risk" means in the end, right? - and who would want to work on such a project?

Digital Taskboards I'm aware of as of 2011-03-11

2011-03-11T11:02:00.003+01:00

At the Agile London usergroup meetup last night the topic of digital taskboards came up and I promised one of the participants to send a link to /one/ of them… since I couldn't remember which one I was referring to (it was kanbanery, I found my note eventually) I went through the list in my head and realised that the list isn't so short any more…

Qanban…a very promising (and free as in speech) project from @xlson which unfortunately doesn't undergo much development right now. But… it's open source, the source is on github - you know what to do!

Kanbanery…got a lot of mentions lately on twitter, but I only did a testdrive

Pivotal tracker…A friend of mine uses that a lot (Cheers @jcfischer) and is quite pleased with it

See Now Do… haven't tried it, but I know the product owner and from that I infer that it ought to be good

Atlassian / Jira / Greenhopper

@Lynne: Sorry - to many to tweet directly

Note to self 14 - Backups don't matter, what you want is recovery

2011-02-03T00:41:00.003+01:00

It really doesn't matter how good or how fast your backup process is - it's fastest if you just copy to /dev/null - if the recovery doesn't work.

This is one of the times when the practices of ITIL and the like are very applicable even to the smallest IT department - like your own personal laptop computer.

Do a trial run of the recovery every now and then!

(At least I was told that ITIL emphasizes these trial runs. If it doesn't – well, to do them still seems like a good idea to me)

Edit: As Robby Raschke said on Twitter: IT Service Continuity Management (ITSCM) in ITIL is where testing your business recovery is a critical component.

Note to self 13 - you can't assign responsibility, it has to be assumed

2011-02-01T12:08:00.001+01:00

Michael, you might be able to say - or even order - that somebody is responsible for something but that doesn't really make them feel responsible for it. If he is assigned that responsibility without assuming the responsibility he will most likely find ways to delegate this responsibility and to redefine the borders of the responsibility.

An example for assumed responsibility would be this guy I know who develops his own software for a living - they lengths he goes to circumvent the glitches of the operating systems are impressive. For example even if the java installations on the client machine are completely effed his software will still try to figure out the best match for his needs and will 'just work' - Although he could just lay back and take a position of "Well, if the user can't correctly install java it's his problem" he doesn't. He feels not only responsible for implementing his software. He feels responsible for the users experience with his software. (And given the fact that he is able to make a living from a $30 software package his commitment seems to pay off)

It's unrealistic to expect this kind of behavior from people who are assigned responsibilities - especially if they don't believe in the goals or the underlying beliefs of the people who try to assign the responsibilities.

Big scale 'Agile', enterprise 'Agile' - what went wrong?

2011-01-29T14:57:00.004+01:00

I'm just trying to understand the idea of large scale 'Agile'
"Apply the principles that we found out to work so well in small groups - which is what makes small groups so successful, because only in small groups these principles can work - to large projects?"
Seriously?
Whom are you trying to be kidding?

Let me put it another way:
1995 to 2008: 7 plus/minus 2 is the ideal team size because of [the usual arguments]
2008 ff. : 'Agile' works so well, lets just apply it to the enterprise level

====8<--------------
Yes I know: the 7±2 team size thing is way older than 1995 - I was referring to usage in the 'Agile' (capital A) community

Note to self 012 - Write it down immediately - with a pen!

2011-01-25T09:24:00.001+01:00

Dear Michael,

your short term memory is mediocre at best - deal with it.
If you've got a bright idea while you're on the phone, write it down. Immediately.
If you've got an important thought while browsing the web, write it down. Immediately.
If you've got a sudden intuition while you're at the beach, write it down. Immediately.

There is a clever toolset designed for this task - it's called PenAndPaper. No, really using pen and paper has some huge advantages over iPhones, Blackberries, iPads and the like.
- You don't have to leave the application you're working with right now.
- You don't have to search for the application
- You can use it while you hold the phone to your ear.

Oh, and it doesn't run out of batteries and even survives coffee spills (albeit at the loss of some legibility if you keep on insisting on using these antique fountain pens)

Therefore, dear Michael: Get back in the habit of almost always carrying a minimum amount of paper and a pen.

P.S.: But of course putting it down on paper doesn't eliminate the need to consolidate the notes at some place - in your case I wuld recommend something electronic, virtual and distributable. Like a plain textfile. A text based mind map might also be in order as long as it really helps and doesn't come in the way.

P.P.S: Oh, and since you're such a keyboard fan - as long as you're on a 'real' computer and can acces your notes faster via a the keyboard that by reaching for pen and paper (e.g. <Cmd>-<Space>, "Scribbles", <Enter> or <Windows>-<R>, "Scribbles.txt", <Enter>) I guess it's OK to use that instead of paper...

Context does matter in UX und UI design

2011-01-22T10:02:00.015+01:00

In a recent tweet a friend of mine (Selena Delesie) stated that she is "Surprised to discover there are programmers who still don't put limits, data type restrictions, and error handling on form fields."

As much as I like twitter I soon came to realize that I couldn't put my answer in 140 characters - not even with unicode tricks.
But I'm not surprised at all - and I don't even think it's a bad thing that there are unchecked fields on forms.

As I said in my reply:
"depends on context & is a tradeoff between effort & possible harm.
user ∈ inhouse dev ⇢ lax checks"
user ∈ public ⇢ strict checks [didn't fit in the 140characters limit]

The scenario for user ∈ inhouse dev ⇢ lax checks

This would probably also be a 'C' or a very small 'D' on the cockburn scale, wich is explained in more detail at Alistair's own site.
If I build a 3-hour effort tool for me and my fellow developers to manipulate database metadata and that is intended to run only on our development machines I probably

won't put too much effort into checks against SQL-Injection - we can do all the harm we want anyway [and it doesn't matter much if we accidentally write "drop database;" in the database's command window or in an unchecked entry field]

won't put to much effort into checks against the wrong type - I'm pretty sure all of the intended users (e.g. me and three co-workers) can handle an error message like "invalid type at line 8745 in <name_of__3rd_party_sql_library>"

won't care if it's possible to enter 4gb of data through one of the entry field - the possible harm is well within acceptable limits for the stakeholders (me and my colleagues) and the harm could be achieved in much simpler ways

The scenario for user ∈ public ⇢ strict checks

On the other end of the spectrum would be a piece of software used by a large number of people who might or might not have have malicious intentions and where incorrect values might cause harm to serious money or even life (that would be a bigger 'D' an 'E' or an 'L' on the cockburn scale IMO.
The classic 'E' example for me is the ATM where I probably

would make sure that only numbers are entered by using a hardware keyboard that only consists of numbers [and check the input values to be a little bit safer with respect to physical attacks]

would replace drop-down boxes by large hardware buttons at the edge of the screen

and so forth

The 'L' examples that come to my mind are mostly related to heavy machinery or medical equipment - in both cases the aforementioned principle - limit the choices and represent data entry through manipulation of physical objects - are heavily applied.
Most application fall somewhere in between and nowadays more and more applications that deal with essential money (e.g. online banking) are realized without the hardware representation. In these cases, especially for applications running on the internet, I would

Put limits on the length of input data - on the client if possible and on the server just to make sure

Make sure the data that get's typed in represents the correct types * as early as sensible [that might be on the client - I'd add a server side check for good measure in all cases and might drop the client side check if it becomes to intrusive for the user.

Implement an error handling scheme that gives helpful information to the use with as much detail as he requests and informs the developers and maintainers of the system of the possible quirks in the system at the same time so that the UX can be optimized to have less occurrences of that specific error in future releases.

The problem with the two scenarios "user ∈ inhouse dev ⇢ lax checks" and "user ∈ public ⇢ strict checks"

is that most applications are somewhere between them. And sometimes application evolve from a little developer-on-the-team-only helper application to something that is used by more and more people so the last responsible moment ** to rework my three our project to a product becomes hard to determine. But if I as a developer kept my options open (e.g. because clean coding has become a second nature) it should be possible to productize the tool.
But - it has to be a conscious decision!
In my opinion it neither makes sense to make a cheap tool cat-proof nor is it responsible craftsmanship to offer a product to the public that doesn't employ proper checks.

* but that is a topic for another article - the only type that a user with a keyboard can key in is "array of characters" - what it represents is 100% context: e.g. "feed" might be a word in one case - it's the hexadecimal representation of 65261 in others.

** See e.g. Mary and Tom Popendiek on the topic of the last responsible moment and the keeping of options. Due to a fancy website design on their side I can't provide a link though - but as of 2011-01-22 the statements can be found after clicking on "focus on learning" in the principles box on the left hand side of their website.

BTW: I really wonder how this page with the "is element of" and the arrows will display on other browsers and systems...

Note to self 011 - Trust takes a lifetime to build - but can be lost at the blink of an eye

2011-01-20T01:29:00.001+01:00

And - as Jerry Weinberg said - no one tells you when they have lost the trust in you!

Note to self 010 - Parkinson's law strikes - again!

2011-01-13T21:51:00.002+01:00

It may not sound very nice, but the sad fact is that people tend to use up the available time for a task in a lot of situations. Therefore: If you want to be over with the meeting in 30 minutes send out an invitation for only 30 minutes - if you make it 45 minutes in the invitation it will take 45 minutes.

Parkinson's original quote from 1955 is:

Work expands so as to fill the time available for its completion.

see: http://en.wikipedia.org/wiki/Parkinson%27s_Law

Note to self 009 - it's called Hanlon's razor

2011-01-13T21:42:00.000+01:00

And it goes: Never attribute to malice that which is adequately explained by stupidity.

Although sometimes Heinlein's Razor or Napoleon's unnamed version of it seem more appropriate...

Heinlein's razor:
Never ascribe to malice that which is adequately explained by incompetence, but don't rule out malice

Napoleon's unnamed epigram:
Never ascribe to malice that which is adequately explained by incompetence.

See http://en.wikipedia.org/wiki/Hanlon's_razor

Note to self 008 - It's not "You are " it is "I observe "

2011-01-13T21:30:00.000+01:00

Dear Michael, [talking to myself as usual] I noticed that you complain about incompetent people. When I hear that I tend to put you in the category "egomaniac". What can we do about that?

Sounds much nicer than: "Michael, you are an egomaniac. I know that because you complain about incompetent people" doesn't it?

Even if you're convinced that the other Person (or team for that matter) is malicious, unhelpfull or in any other way "bad" remember that that's just the way you perceive it. Talk about yourself - that is something you can be sure about and that can't be argued away. [It is very hard to tell somebody "no, you do not feel that way" - although sometimes there are people who try.]

Note to self 007 - I still can't handle incompetent people

2011-01-11T23:16:00.002+01:00

More a point I still have to work on than an actionable note to myself:

Don't get overconfident. It's not enough that somebody is incompetent - you've got to be able to convince people of this seemingly obvious fact. If you can't pinpoint it - just let it go for the moment. Especially if you can't put a number to the incompetence.

As a matter of fact this is something that I've never really gotten around to.

[Explanation of the note for reader who are not myself]

There is a certain kind of incompetent people (e.g. they just have no expertise in the very thing they are doing, they are literally incompetent in such a way that they lack the competences that they need to perform their job) that I still don't know how to handle - those that don't know the details of the job their doing but are yet well versed in easily graspable abstractions of the work they should be doing.

The only way to handle these people - who sometimes have a real bad effect on the morale of whole teams - seems to be a very detailed breakdown of their shortcoming. But that on the other hand leaves me in the position of a nitpicker [erbsenzähler] who wastes everybodys time - including my own - by going through seemingly unimportant details.

Of course - applying the rule of three - that can't be the only solution - but although I've been trying for years I haven't been able to find any other angles. At leas not up until now - still trying!

Notes to self 006 - Be aware of the focus of the reciepient

2011-01-11T22:38:00.002+01:00

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.

(Wish I had thought about that two weeks ago)

Notes to self - 005, Get it in writing - even if you have to put it there yourself

2011-01-10T01:13:00.002+01:00

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.

Notes to self - 004, Keep local backups - The Cloud might dissolve

2011-01-05T18:00:00.005+01:00

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.

Notes to self - 003, Write each email as if it will reach your worst enemy

2011-01-05T17:33:00.003+01:00

=====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 ----

Notes to self - 002, Keep Records! Measurement & Calculation beats guesswork

2011-01-04T00:19:00.007+01:00

=====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 ----

Notes to self - 001, Always put up a visible agenda

2011-01-02T21:30:00.009+01:00

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:

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)

Estimate - 'an' or 'to'?

2010-06-24T23:29:00.002+02:00

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?

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

2009-09-30T09:15:00.002+02:00

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.

Cheerio

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

2009-09-20T15:03:00.003+02:00

...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?

2009-08-23T14:27:00.006+02:00

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

2009-08-05T22:16:00.004+02:00

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

2009-04-02T17:30:00.004+02:00

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)

scm & build: Levels of configuration

2008-09-29T23:58:00.011+02:00

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...

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_

Best Practices - like everybody does it?

2008-09-18T10:28:00.002+02:00

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_

Build-, Version-, Configuration- and Sourcecodemanagement,

2008-09-15T12:03:00.006+02:00

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

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

but also things that seem to be intuitive to some but controversial to others

Command line builds
To branch or not to branch

and more conceptual topics (the most important to me) as

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_

Strange ordering...

2008-06-08T00:42:00.003+02:00

Strange - a few days ago I finally edited and released an entry from about a year ago - it still shows up in the old position.

So - just to make it evident that I'm writing a little more again - I wrote this entry. The post in question was about the simple but disputable question "Are technical topics no business topics?"

Agile discussed by Jerry Weinberg

2007-09-06T13:19:00.000+02:00

In an interview with PMBoulevard Gerald M. Weinberg states his opinion on agile Methods.

From that interview:

Q4: What is the future of Agile?
First we will drop the capital A. Then we will drop the term "agile" altogether. Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.

That even someone as renowned in the field of "conventional" software development as Jerry Weinberg points to the common sense embodied in these methods makes me hope that someday the waterfall-style methods might vanish alltogether.
(via Jerry – of course)

Divas and Geniuses

2007-08-25T15:10:00.000+02:00

In a blog entry from the start of the week Mark Masterson cited from the lessons learned document of a past project:

"Change the design / architecture to reduce reliance on the divas"

That reminds me of a former client of mine who used to say

"If you've got a genius in the team - get rid of him"

At first that's rather sad, but after a while - and with changing responsibilities - I came to realise that there can be situations (actually lots of them) where the advise is absolutely sensible.

It can be sensible because most developers are of average capabilities!
After all - that is exactly what average means.
Therefore the probability to have "above average" developers declines with the size of the project (and the organisation) simply because of the definition of average.
Even if all (or at least almost all) the developers in a certain team are "above average" (e.g. compared to some outside group of reference developers) most of them will - by definition - be of average skill within the team. That's where the "get rid of the genius" sets in.

If one of the persons on the team is way ahead of all the others - lets say she is a specialist in compiler construction - their advantage can become a disadvantage for the team as a whole. For those "geniuses" TSTTMPW (The Simplest Thing That Might Possibly Work) probably is quite different from the things the rest of the team perceives as "simple".

Configuration files are a good example - while plain text with very little syntax is the "simple" thing for most of us a specialist in compiler construction wouldn't mind using a sytax that is "syntactically a little richer" to gain simpler implementation. He might end up with a configuration language like sudoers' - where guides to the grammar (defined in EBNF) and the grammar's grammar are provided in the manual pages just to give the average user a chance to understand sodoers.

Actually I worked on a compiler project myself way back in the 80ies and used to be kind of fluent in BNF, but figuring out sudoers still took me a while. And judging by the amount of

<username> ALL=(ALL) ALL

(basically: allow <username> to do everything he wants as root)

that I've seen on other peoples Macs not many of them go to great depth deciphering the format...

Back to projects: Of course the idea to get rid of every smart person in the team would not be the best option - unless you want the project to fail.

But the "geniuses" - or, to be fair: those who have advanced knowledge and/or experience compared to the rest of the team - have to be handled carefully. Only for very isolated tasks they should be left to work it out all alone.

For the rest of their work they ought to work closely together with other team members as long as their personality allows them to adopt their ideas to a level thats appropriate for the whole team. Should the latter not be an option then option one is valid again of course - the team should get rid of 'em.

But in my experience that is seldom necessary Most geniuses are quite willing to agree on a sensible level of "simple" as long as their is a sensible discussion.

So after all it no so sad anymore. The bottom line of my job is not to get the "best" possible solution but to make the team as a whole as effective as possible

_MM_

Contracting Principles by Gerald Weinberg

2007-08-19T12:17:00.000+02:00

I may not agree with everything he said, but the principles lined out by Jerry in his post on how to prevent consulting misery are a good starting point for everybody who is trying to figure out how to shape their relationships with their clients in a healthy way.

New Blog in Town

2007-07-16T23:11:00.000+02:00

Since not all the things I want to talk about are really that relevant to an international audienc I just started another blog for the local topics.

...ups wrong link at first - sorry ...

From Cavedrawings to Hyroglyphs to Times New Roman - and back to Cavedrawings.

2007-07-06T20:40:00.000+02:00

Sometimes I don't understand our business...
Just recently I listened to an interview with Grady Booch where he (once again) emphasized that he never intended the UML to be used for programming (i.e. as a programming language).
I‘m a proponent of visual modeling myself and after experiencing the method wars of the nineties I'm glad that such a thing as the UML unifies the meaning of arrowheads, boxes and dashed lines.
But I just can't understand why people think that they will be able to describe complete software systems of all kinds in pictures (although it's quite possible for some domains and to a certain level).
When thinking of the written word and picture I just can't avoid to think about cave drawings and "real" writing.
It‘s very common to judge the development of a civilization by it‘s capabilities to write. Or as Wikipedia puts it:

„Historians draw a distinction between prehistory and history, with history defined by the advent of writing. The cave paintings and petroglyphs of prehistoric peoples can be considered precursors of writing, but are not considered writing because they did not represent language directly.“

So where does it put our so called "industry" when some of us attemp to describe complex systems in pictures alone?

Talk: "methodological software development"

2007-06-13T01:18:00.000+02:00

As I said - I'll try to keep this more current...

As mentioned in my previous post I just returned from my talk at the GI in cologne and besides the issues with the colour of my slides I think it went quite well.
I surely would attend the GI meetings more often if only they where not on tuesdays - the athmosphere was rather open and the discussions gave some rather interesting pointers.

For those who would like to see the slides again: You can download them from www.michaelmahlberg.de/GI-MethodenMichaelMahlberg.pdf. But you should be prepared for a somewhat lenghty download - apart from the "slightly" dark appearance on screen a textured backdrop tends to create large pdf outputs... in this case about 10 Megabyte...

Lessons from my last talk

2007-06-13T00:06:00.000+02:00

As some of you may know im a big fan of Presentation Zen and try to follow some of the ideas in my talks. Today I was reminded of a few lessons I should have thought about beforehand:

No matter how cool your slides may look with that subtle gray-in-black backdrop and the translucent, intersecting areas - don't rely on it. Always keep a second set of slides handy that is optimized for bright ambient lights if you can't check the location beforehand! It's not important how it looks on your screen or in your controlled environment - it's import how it transports your message during the presentation. Therefore: bright coulours and high contrast for all unknown environments (at least as a backup).

Although I believe that a presentation is not the set of slide (i.e. you can never mail a presentation to someone - you can only mail the slides) I tend to put some effort in slide-design and so they ought to look good.

The other point is file size - since I converted to the Mac I tend to adopt a somewhat disrespectful attitude regarding the size of elements I use in a presentation - that's allright as long as the main point of the slides is to support the talk. As soon as I want to distribute them I could be running into trouble - for example when a simple 37-slide slideshow results in an almost 10MB pdf...

regarding the talk itself ... see next post

Upcoming Talk(s)

2007-06-06T19:16:00.000+02:00

Following some examples from colleagues I'll try to post a little more information on my upcoming activities. Right now the list contains only one talk, but I'll try to keep the information on this blog more current in the future.

I'll hold a talk on the state of the practice of "methodological software development" for the Cologne chapter of the GI (Gesellschaft für Informatik / German Chapter of the ACM ) on June 12.
The talk will give a quick (20 minute) overview over practical experiences with applied development methodologies from SADT and IEM to XP and Scrum over the last two decades.
Unfortunately the website is not quite up to date yet, but at least the location plan ought to be correct.

BTW:
Is "praxis-talk" really a legal english term?

Are technical topics no business topics?

2007-06-02T00:49:00.002+02:00

I started to write this about a year ago - I think it's time to finish my earlier posts to get at least the basic ideas behind them in writing before I try to start new topics.

Every now and then I come across the silly notion, that technical decisions - like "Java Yes, Ruby No" - are considered to be "not of business relevance" and are to be left to the "IT department" since "the business folks wouldn't know anyway".

Apart from the inherent hubris from "IT" people with that attitude I think this point of view is rather short-sighted. If there are implications the business is not aware of it is the solution providers responsibility to inform the business people.

But - getting back to Java vs. Ruby style questions - to build a certain application with an estimated life-span of 6 month (e.g. because there is a legal requirement for exactly that time-span) might be a sensible thing to do in language 'Y' while it may be more sensible to assign two interns to do manual data corrections than to build an application using language 'X'.

You may substitute X and Y in the above paragraph with Ruby and Java respectivly according to your personal bias (or - for that matter - with any pair of programming languages) but the business people really should have a the last word in the decision.

ceterum censeo: We (including me) should really stop using the term "IT" ... if only I knew a suitable substitute ...

Dictatorship of the Dominant Decomposition

2007-06-01T08:56:00.001+02:00

Well I thought this was well known, but obviously it isn't - a least outside the aspect-oriented crowd. So here are a few pointers for starters.

As a matter of fact I was wrong about the phrase though - it is called:

The tyranny of the dominant decomposition
(scroll down a little in the Glossary)

The original Papers can be found at ibm's reasearch site. Opposed to the AOSD glossary my preferred paper is the one about Multi-Dimensional Separation of Concerns. The one about Morphogenic Software is still worth a read though.

MacBooks on the Rise: Tools revisited

2007-05-31T13:23:00.000+02:00

More and More of my friends, colleagues and acquaintances turn to Mac OS X so I think its time to revisit my list of essential tools.
The List is based on personal experiences and my starting point were:

Lets start with some picks from Stefan's list (for a detailed discusson of the applications he used to like at the time see his list):

Stefan's Emacs is (of course) replaced by vim/gvim on my list - unfortunately not as nicely ported as on Linux and Windows - but it still does the job for me.
Quicksilver definitely is a must - when working on windows one the the shortcuts I use the most is Windows-R (Run a single "Command"). Quicksilver goes far beyond that and is indispensible on a Mac when you're a keyboard addict.
Terminal (iTerm) omitted - no advantage for me. I'm happy with the built-in Terminal.app
The Omni Group's productivity suite was also very basic (not as in "simple", but as in "need to have") stuff - at least if you have to organize thought and discussions (OmniOutliner) and draw expressive diagramms and pictures effectively (OmniGraffle). The browser (OmniWeb) was a nice add-on but tends to interfere with my powersaving options so I switched back to Safari (the built-in browser). Unfortunately the productivity suite seems to be no longer available - wich makes it easier to focus on the important products.
Talking about browsers: Of course different browsers like Camino and Firefox come in handy if I use any Web2.0ish sites (and how could I avoid them nowadays)
Instead of ecto I went for Qumana for blogging - and ended up using a texteditor, and OmniOutliner for the job ;-)
I always preferred Addium over Proteus, but since AIM- and ICQ-user can also be reached via the built-in iChat I don't use any of them any more. For more compatibility with windows users Skype (> 2.0) comes to the rescue.
Ssh-keychain: well - yes i use it too.
And allthough I do very little development on my Mac Eclipse really does a great job for those little chunks of java that come along.

Now lets look at my ~/"Application" and the main "Application" folder.
Here we've got (noteworthy only):

Productivity

I can't work without a mindmapping tool. My Choice is Freemind - a java based application that runs nicely on Windows and OS X. And with a little finetuning it even shows the brushed metal look and feel of OS X.

Another "promiscuous" application as Larry Ellison might have said in the early eigthies is GanttProject which also runs on windows allmost as well as it does on a Mac. A simple but effective tool - for those situations where you just have to visualize your plans in such a way - that is written in java..

Every once in a while I have to make a little note. Using quicksilver I usally just start up a texteditor, make the note and save the file to the desktop. But I'm trying to change to sidenote - it would be so much easier...
AquaPath (again a recommendation from Stefan) to play with XPath expressions.
I'm quite happy with vim/gvim (I think I mentioned that already ;-) ) but sometimes a more GUI-ish editor is helpfull. That's where Smultron enters the scene - I'm not yet in the need to get Textmate.

Not necessary but nice

The MBPs are known for there "offensive" thermal behaviour. And even though I know that there is little to worry about I still like to check with Temperaturmonitor.

WordPod is a nice little tool to transfer textfiles to an iPod for reading - not heavy in use but usefull.

AudioRecorder as a lightwight alternative to firing up GarageBand just to record a few minutes. Saves directly to an AIFF, Apple Lossless (M4A and MOV), MP3, MP4 (M4A and MOV), or WAV file.

The office stuff

Pages and especially Keynote are some great alternatives to the standard MS-Office apps. So iWork was one of my first aquisitions (actually I ordered them together with my Mac)

But still - since most of my clients are hooked on Microsoft MS-Office is a must.

And for those who try to avoid the MS-Office trap and turn to OpenOffice NeoOffice is my choice of interaction.
Whenever I have to fiddle with graphics that I can't handle with OmniGraffle or the built-in apps (iPhoto does it for 99% of my photo editing whishes) Posterpaint and Seashore come to the rescue.
The essential tool for web development of course is a texteditor! ;-) But the way CSSEdit lets me fiddle with css styles is unmatched by anything I've seen before. Coda might turn out to be a great addition, but im not yet sure.

Being the lazy person I am I try to avoid typing as much as I can. RapidoWrite helps me by replacing abbreviation with any text I like (as long as I've defined the abbreviation of course)

One of the nice things about OS X is the fact that pdf is a native format. Still some tools come quite handy for some Tasks.

PdfMergeX gives a little more flexibility to the handling of pdfs.
PDFView is an alternative to the built-in Preview application and is in some ways more "natural" to the eye.
Although many printer drivers allready support "brochure" layout CheapImposter is my tool of choice if I want to be able to create brochures on not-so-smart printer without duplex capability.
With Yep! there's a great alternative to searching pdf all over my harddrive - and I really should use it more ...

System tools

SyncTwoFolders does exactly as the name implies - great for keeping USB-sticks up to date.
Going back in broser's cache is not always easy - but Retrospective makes it easier.
Even a nnn-GB drive gets stuffed after a while. With Filelight and GrandPerspective it's easy to identify the hotspots - actually I use almost exclusively GrandPerspective - Filelight is just an alternative for "special cases".

Connectivity

As always the Mac (at least mine) just works when it comes to wireless networks. But sometimes I want to now why and how. iStumbler doesn't tell me to much about my system - but it tells me all (almost) I want to know about the WiFi networks in my vicinity.
And once I'm connected to a network Flame tells me wich bonjour services are available. (Run in an airport lounge just for fun - it's amazing how many people intend to share their music and printers whith everybody. Especially considering the fact that you deliberately have to turn on sharing in OS X)
The built-in Mail.app does almost exactly what I want - but sometimes I just want to check my mailbox just to see if it's expedient to burn bandwith (think of UMTS/GPRS in aforeign country) by really accessing my Mailbox. Thats where MacBiff - an IMAP-savy menu extension is exactly what I need.
Even Apple doesn't always get it right - to really get the best compatibility with my Palm I needed to install the MissingSync. Now everything works fine.

Multimedia

VLC - any questions? Handles all the video formats out of the box.

But when I use Quicktime I sometimes would like to run it fullscreen. Thats very easily possible by sendig AppleScript command to the player - even without the "Pro" version. Fullsceen4Free does exactly that and includes a (nice?) GUI.

Before CoverFlow was integrated into iTunes i definitely liked it better. May or may not be available in the future. Last download possibility I knew was at MacUpdate

One of the esential tools for iTunes is of course beaTunes. This tool analyses Songs not only by BPM but also by "colour" - kind of representing the overall mood of the song - and really helps building better playlists.

And - last but not least - the system extensions I use

Although not really necessary, Growl is very helpfull when many application are running in the background and their user notification shall appear at least somewhat co-ordinated.
As you might have guessed by my use of Temperaturmonitor I really like to know whats going on inside my machine. MenuMeters provides exactly the information I want.
Even though the MDI-Interface is the standard for OS X applications there is no standard way to acces all the windows vie the keyboard. Witch gave me back the capability to "tab" through all open windows. (Arguably thats not really necessary once one gets used to exposé)

Oh - did I mention dashboard widgets?
But it's getting late, my battery is almost empty and I still got a lot of other work to do - so here's just a taste...

Upcoming Birthdays
AviationWeather
ColorJack: Sphere
SecretNotePad
iStatPro
Stop It!
and many, many more

You want better estimates? Give us more dice.

2007-03-14T01:54:00.000+01:00

I'm not sure whether the title works in English, but regarding the way projects are installed in some companies I started to attain the aforementioned attitude.

This is especially helpfull in situations when you're asked "We're not yet exactly sure what we want - but how much will it cost?"

In German: "Ihr wollt bessere Schätzungen? Gebt uns mehr Würfel!"

Powered by Qumana

The 'T' in 'IT' is the worst thing ...

2006-12-18T21:48:00.000+01:00

...that happened to 'IT' in the last decade.

Once upon a time...
the craft of software development was performed under the umbrella of data processing and those performing the tasks had titles like programmer, designer, analyst or something along that line. Some of them even came from "computer sciences" or "informatics" but: all of them acted on data or information.

Nowadays - I'd say since the late nineties of the last century - there seems to be a clear line between "business" on one side and "IT" on the other. That wouldn't need to be too bad, but since the "T" in "IT" stand for "Technology" it is.

The "Technology*" metaphor affects both sides. Developers, projects managers and even (software) analysts and designers just take the input - be it concepts or orders or functional descriptions - and try to implement it (or design the system) as good as they can. Business analysts - or who ever describes the content of the project - concentrate on their part of the story and ignore any technical implications.

Sounds fine - doesn't it?

Unfortunately it does! But this seemingly sound separation of concerns is in fact one of the main reasons for time-and-budget overruns, immense time to market durations and similar problems (aka "the new software crisis").

Lets have a slightly closer look at the problems arising from that separation.

Technology & method savvy people get confined to the "techno-space"

Putting all those people with systems design education and experience on the technological side of the imaginary "IT fence" leaves no-one with up-to-date knowledge on the business side of that "IT fence". Of course some business analyst are happily nudging away on the business side of the fence, but they are clearly in the minority.

Most businesses are un-precise by definition - so that is what the business people need to be

To be successful in business a certain degree of leeway is absolutely necessary - people (and most customers are people, even if some of them - namely some of those from the centralised purchasing departments - try to hide the fact) are extremely informal in their perception of the world and in order to generate business you'd better be flexible too.

Business problems don't have to be hard to be expensive - it's sufficient if they are based on "common knowledge"

In the early time of software development software simply was the only way to solve very complex but well defined problems. Finding the correct trajectory to shoot three people from florida to the moon would be one of those well defined but complex problems. Later on there came other types of problem: seemingly simple problems with ambiguos definitions - lets say tax collection. Although theses are 'not exactly rocket science' and you easily get along with the four basic calculation types there are volumes and volumes of law textbooks and interpretations even for one type of tax.

The problem gets worse when people try to describe - or even define - a process 'unambiguously' without proper knowledge. Just try to describe the behaviour of a lift without diagrams. Now add time-awareness and route optimization. And add a second lift, coupled with the first one.

Formal methods should be applied much earlier

Now if you thought of all those fancy diagrams from one of your favourite methods to describe the problem above your probably living rather close to the "T-fence". I personally cross the border very often - either from one assignment to the other or during one single assignment - and every time I introduce some little formal method to business people I am overwhelmed how fast and efficient these methods are applied. It's not that these business people are dumb or ignorant - the problem is just that they don't have a focus on formal methods and are often actively separated from them by the IT-departments.

Agile processes try to circumvent this problem but fail to consider typical german mindsets

It's not only that business and IT use different (formal) languages but also the distance a piece of information has to cover to get from people thinking "business" to people thinking "systems" and back. So the poor guy trying to implement something has not only got to figure out how to implement it but also "what did he/she think that he/she thought what he/she was thinking - and what the heck could be the business reason behind all of these interpretations?". These assumptions - made by the last poor guy in the line - are what eventually make the systems work.

In my opinion the agile processes are a very good way to bridge the distance from business thinkers to systems thinkers (e.g. by placing them very close together) but they unfortunately fail to take local (in this case German) mindsets and organisational patterns into account.

To effectively overcome this situation the "fixed price addiction" (as one of the more direct agile protagonists once put it) has to be overcome - but I'm afraid that will still take a while. In the meantime it could help offer more support to business people earlier.

"bring together, what belongs together"

On the other hand it might be a good idea to allow for more business awareness in the IT-Departments to become more of "systems thinking departments". Although most of the systems work in the end they could get there much faster if the implementing departments would be willing to think more business oriented.

Although this will probably not happen any time soon (at least in Germany) this is one of the occasions where a small step backwards might turn out to be a giant leap forward. So perhaps it's not only about insourcing ousourced IT-departments but about integration of IS knowledge.

Stop using the term IT, make it IS (Information Systems) or something even more appropriate.

Any suggestions?

* BTW: It is even worse with the german word "Technik" because that is often interpreted as "mechanics".

Powered by Qumana

Reuse considered harmfull?

2006-10-19T15:36:00.000+02:00

Although sometimes treated like the "holy grail of the software industry" reuse has never appealed to me as a primary goal.
After I discussed this topic with Olli (sorry: no blog, no personal homepage => no link) last week he dug up the diploma theses from Rupert Stützle (in German) called "Wiederverwendung ohne Mythos" (roughly: "Reuse without myth") which puts a little foundation behind my gut feeling.

I've personally always considered reuse to be an indicator of good architecture and design but the real goal for me is to to have flexible systems where the change impact is as localised as possible. I'll have to take a look at the theses to see if that point of view is also backed up by hard facts.

Powered by Qumana

Location Changer: Good Idea, unlucky (for me) implementation

2006-09-03T11:29:00.000+02:00

I just gave WiLMa a try run and prompty had to reconfigure my mail system. Here is an excerpt from my mail to the author:

One of the great things in apples Mail.app (unlike the last version of T-Bird I tried or some other mail clients) is that it handles SMTP-Servers on an account basis.
I don't use an open SMTP-Gateway and I neither like nor encourage open SMTP-Gateways. Therefore each of my outgoing mail addresses (private, business, community work) has to use its own SMTP Server/Gateway.
The first time I started WiLMa and went to the 'SMTP Servers' pane I knew I was in (mild) trouble: Only one SMTP-entry...
I switched to Mail.app and guess what: All accounts already bore the same entry for their SMTP-Servers. And obviously one of them even disappeared from the list (probably because I have two account on the same machine).

At least my other system settings were left alone (sigh), and it only took about 10 Minutes to reconfige the accounts. (Testing included)

Update, less than a day later:
I just got Mail from the author - he really seems to be very responsive, so I think I'll give it another try in december.

Here's (part of) what he wrote:
[...]As for the software's initial behavior, I hadn't thought of it from that angle and will try to get this fixed in time for the October release. Perhaps an opt-in for features instead of an opt-out would be a good solution?[...]

Powered by Qumana

O/R-Mapping: A loose-loose situation?

2006-08-31T21:27:00.000+02:00

Today (while researching SOAP-Bindings...) I stumbled across a great (and comparatively recent) article from Ted Neward where he compares O/R-Mapping with the vietnam war. Although this seems a little unpopular to some I'll have to go deeper into the article as time permits. From a first glance I have to say that I couldn't agree more (at least on the technical side)

Powered by Qumana

Cynical Reengineering ?!?!

2006-08-27T00:23:00.000+02:00

I'm not shure really about it right now, but Daniel pointed me to an article about "Cynical Reengineering" wich really appealed to me from the title alone. I'll have to go deeper into this as soon as I find the time.

Powered by Qumana

Online Feed reader

2006-08-23T13:15:00.000+02:00

Sometimes it's usefull to read your feeds - like blogs or update sites - via a browser.

From Stefan I learned about bloglines which seems quite OK - except that the confirmation mail they sent me was "considered spam" by Apple-Mail (at least it passed my providers Mailfilters ;-) )

Might be a handy way to stay up to date when no internet-access is available for my laptop.

Powered by Qumana

Automated acceptance tests @ agile-cologne

2006-08-19T00:49:00.000+02:00

tonight at the 15th meeting of the agile cologne user group (in German) Andreas Thiel reminded me (and all of us at the meeting) of an important statement from the Fitnesse Website (cited a bit liberally):

Unit tests help to build the system right

while

Acceptance tests help to build the right system

A good thing to remember!

Powered by Qumana

Thats why.

2006-07-07T00:34:00.000+02:00

Today I learned about the real reasons behind working Software - it's all based on quantum-theory... (via Burghard)

If you don't know which framework to use..

2006-05-18T14:05:00.000+02:00

... look here

Mac OS X newbies

2006-05-17T19:10:00.000+02:00

Perhaps this thread should be read by all Win to OS-X convertees. Although it's a little long it's worth scanning through it.

OS-X Simple Graphic Tools

2006-05-17T18:27:00.000+02:00

One thing - apart from the cd-copy stuff - that really bugs me in OS-X is the absence of anything even remotely resembling MS-Paint. I suppose most Mac users own some Version of Photoshop or the like but I'm a consultant and developer not an artist that's why I'd like to have something lightweight, easy and free.
After some googling I found
Seashore (probably a little heavy)
Seashore
Seashore
and
Posterpaint

let's have a look at them... more to come
-mm

P.S.: Drawing could be done with
Inkscape or
ArtRage 2.1

Links again: XPath-Turorials

2006-04-26T17:32:00.000+02:00

My ressources for XPath
http://www.w3schools.com/xpath/
http://www.oreilly.com/catalog/xmlnut/chapter/ch09.html
http://www.w3.org/TR/xpath

Links again: Functional Testing

2006-04-26T17:24:00.000+02:00

Open-Source tools for functional testing can be found at

http://opensourcetesting.org/functional.php

Links mal wieder: Webtest-Support

2006-04-26T13:36:00.000+02:00

A number of usefull tools aimed primarily on testing web applications

http://webtest.canoo.com/webtest/manual/annotatedRefs.html

Moving from windows to mac

2006-04-11T22:11:00.000+02:00

Well, since a week or two I own a shiny new MacBook and I think it's time to wrap up my experiences so far.
Although I spent a few night trying to get the new feeling I was able to be productive almost from day one.
The build in Apps are a breeze, Mail does just what it's meant to do, the browser works like a charm and after installing the PalmDesktop my Palm synchronized (almost) perfectly with iCal and the addressbook. I only miss the categories but i'll have a look at the MissingSync (for Palm OS) and I might be completely happy again;-)

[posted with ecto]

Joining the crowd

2005-12-30T12:40:00.000+01:00

Well - this is actually more of a technical post since I just created this blog and want to see if it works.
More to come later...