Dynamic Software Development

What if the client doesn't read the specification?

2008-05-08T07:38:00.001+02:00

One purpose of a specification is to verify the communication with the client. But how do you handle situations where the client signs it but refuses to read it? This client has a very specific knowledge but no time to review specifications. I deal with this by discussing a very brief description of the key topics with him.

What would you do?

New Site - Just for Fun

2008-04-01T08:19:00.003+02:00

The harder they come the more you need fun. I recently created buyabyte.com the web site where they sell rock solid bytes. It's just for my own fun but maybe it's also an encouraging break for others confronted with the daily lunacy of life.

Two-Step Software Development Methodology

2006-09-06T10:29:00.000+02:00

Installation instructions for my WLAN-DSL-Router:

Unpack box
Insert CD
Follow instructions

The last step consists of "some subitems" that describe how the hardware has to be installed in various scenarios and how to set the - about hundred - configuration parameters ...

... and here comes the Two-Step Software Development Methodology:

Understand problem
Implement solution

Not to mention that both steps comprise "some subitems".
Isn't it all about abstraction?

Software Development:Dr. Dobb's | Quick-Kill Project Management | June 30, 2006

2006-07-10T14:01:00.000+02:00

In Dr. Dobb's Quick-Kill Project Management June 30, 2006 Andrew Stellman and Jennifer Greene describe a minimized project management approach. I like the idea to apply it on projects with an impossible schedule. Maybe it's also worth to be considered on those "temporary" mini solutions that are implemented "informal" so far. However, give the article a look. Great content, condense writing.

Software Development:What, How or Why?

2006-07-10T10:36:00.000+02:00

Many software development advisors address the topic of asking "What not How". Edsger Dijkstra showed in one of his early publications (197x ?) that "What" is just another level of abstraction compared to "How". On the next level every "What" becomes a "How". Therefore I think that this advise is misleading. It's needed to know the "What" and "How" on every level but to understand the requirements on any given level we have to ask "Why are these requirements specified?". Understanding the reasons may lead to a different design or allows to suggest alternative requirements suiting the goals better.

Software Development:Creating Passionate Users: Featuritis vs. the Happy User Peak

2006-06-30T09:38:00.000+02:00

In her post Creating Passionate Users: Featuritis vs. the Happy User Peak Kathy Sierra shows "The Featuritis Curve". If I had to position software development methodologies, frameworks or tools on the diagram most of them would rest on the very right - far from the peak!

Software Development:Recommended - free - tools for development, productivity and security

2006-06-27T15:44:00.000+02:00

Brian Di Croce shares his list of Recommended tools for development, productivity and security on his blog The Strong Cross. I don't know all of the tools listed but I like those I know and will have a look on the others.