Friday, February 26, 2010

Phrases that should set off an alarm in every software developers brain

In software development there are some requirements that should immediately trigger all available bells in your subconscious alarming system:

This must be in real-time
The system must support historisation
The system must support multitenancy
The system must provide reports for every screen.

66171.jpgUsually those sentences are just mentioned as side notes or in the small print, as if they go without saying anyway and are the most evident thing in the universe.

But usually they imply a huge communication gap, that can cost buckets of money and bring wagon loads of grief.

Do you know other requirements that fall into the same category?

Update: @asztupak on twitter
It should support all features the previous system had

Update: Comments on Hacker News

Inspiring talks

reality-check.jpgSometimes we have to look beyond our noses. This is especially true when we are getting bogged in the trenches of corporate IT, getting lost in the big ball of mud, filling our brains with WTF from reading wagon-loads of legacy code...
Here are two inspiring talks by two brilliant minds:

"Unlearn your MBA" by David Heineimeier Hansson:

And the already classic "The Art of the Start" by Guy Kawasaki:

Wednesday, February 17, 2010

Software: Sadly we did adopt from the construction analogy

great_pyramid.jpgIn the software industry we often use analogies from civil engineering. We use terms like "architecture" and "construction".

But there is a common claim that we should learn more from classical engineering disciplines like civil engineering. According to that claim the IT industry would be a better place if we would adopt best practices from the latter.

On the other hand there are sophisticated explanations why software projects cannot be compared to construction projects.

Now that's all nonsense! The following quotes show that we actually do adopt eagerly:
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Software and cathedrals are much the same – first we build them, then we pray.
- Sam Redwine

Friday, February 12, 2010

The Agile Testing Quadrants

Discovering the Agile Testing Quadrants was close to an epiphany to me.
They helped me to think much clearer about the different concepts, disciplines and fields of software testing.

The original concept is from Brian Marick, but the quadrants are discussed in depth in the brilliant book "Agile Testing" by Lisa Crispin and Janet Gregory.

There is also a presentation from Agile Vancouver 2008 held by Janet Gregory.

A project can draw different benefits from each of the testing quadrants:


Traditional software testing focuses almost exclusively on the right side, critiquing the product but not playing a productive part in supporting the creation of the product.
Traditional software testing is involved late in the development process to detect bugs but not to prevent them.

The lower left quadrant is the typical developer testing. Unit-testing and integration-testing, hopefully automated and with continuous integration, are quite common practice today.

The upper left quadrant is where we are entering quite new territory compared to what is common practice in the industry.

It's here where we place Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD). Those are quite new agile methodologies that focus on improving quality by placing activities from testing early in the development process. Those activities are constantly supporting the development process throughout its whole duration.

However it's important to understand that all testing quadrants are important. It's not that focusing completely on one quadrant can make the other quadrants completely obsolete. However a well tailored testing strategy uses all quadrants appropriately to improve testing as a whole. Depending on the concrete project the different quadrants have to be wighted accordingly.

Wednesday, February 10, 2010

.Net Quick Tip: Programmatic Check if a PDF Reader is installed


A possibility to programmatically check in .Net (with C#) if a pdf-reader is installed:
public void CheckPdfReaderAvailable()    
	RegistryKey key = Registry.ClassesRoot.OpenSubKey(".pdf");    

Checking if Excel is installed can be achieved the following way:
public void CheckExcelAvailable()
    RegistryKey key = Registry.ClassesRoot.OpenSubKey("Excel.Application");

Wednesday, February 3, 2010

Swarm Programming - Scaling Pair Programming

3600672192_f281a5a995.jpg This is another tidbit from Dan North at the parkbench panel discussion on the Agile Testing, Specifications and BDD exchange.

If I remember correctly the topic of the discussion was about the topic if software engineering is really an engineering discipline or rather a craftsmanship:

Are you sure that what you do is software engineering? NASA is doing software engineering!

In commercial software the average cost for a line of code is estimated at 5$.
At NASA the average cost for a line of code is 5'000$.

They are not just Pair Programming, what they do could be called Swarm Programming!

Tuesday, February 2, 2010

How to debug your code with cuke4duke

cucumber.jpg Cuke4duke is a ATDD/BDD tool for the JVM. The tool is based on Cucumber and uses JRuby to execute.

Out of the box cuke4duke offers three main ways to execute: Ant, Maven or cuke4duke-commandline.

But all of those three approaches are a bit tricky if you want to debug your application when executing in a BDD scenario.

There is some information on the wiki how to achieve it.

Here some more details:

Maven and Remote Debugging

When using Maven, you can add the following lines to your cuke4duke config in your pom.xml:

(a running example is here)

When you now run the integration-test phase (ie. mvn verify), then Maven breaks and waits for a debugger to connect:
[INFO] [cuke4duke:cucumber {execution: run-features}]
[INFO] Listening for transport dt_socket at address: 4000

Now you can connect with Eclipse with a new debug configuration (Run->Debug Configurations...). Choose 'Remote Java Application' and configure the same port as you configured in the pom.xml under address:
Screen shot 2010-01-10 at 4.06.36 PM.png
Now execute this debug configuration, and Maven (which is still waiting) will continue after Eclipse successfully connected, and any breakpoints you set in Eclipse will trigger.

Running from the IDE

Another way is to execute the whole enchilada (JRuby, cuke4nuke, cucumber…) directly out of the IDE. In Eclipse this is accomplished with a new Debug Configuration. Choose Java Application then configure it accordingly: Main class: org.jruby.Main
Screen shot 2010-01-10 at 4.13.57 PM.png
Program Arguments:
${M2_HOME}/repository/.jruby/bin/cuke4duke ./target/test-classes features

VM Arguments:
Screen shot 2010-01-10 at 4.15.02 PM.png
Classpath: Make sure all needed jars are on the classpath.
Screen shot 2010-01-10 at 4.15.17 PM.png
Now execute this debug configuration and Eclipse will break directly at any breakpoint you set in your sources.

Monday, February 1, 2010

Podcast: Scrum in Fixed Price Projects

OnTechTalksMind-Icon.jpg In the first episode of TechTalk's podcast Christian Hassa interviews Mitch Lacey about the applicability of Scrum in fixed price projects.

They talk about common misconceptions, pitfalls and dangers and how to avoid them. Mitch also presents some patterns that worked in his experience.
The podcast is in english.

You can download the podcast directly or subscribe to the rss-feed or subscribe to the podcast in itunes.

BTW: For people living in Switzerland or Austria: This February Mitch is holding his Certified Scrum Master courses in Zürich (8.-9.03.2010) and Vienna (11.-12.03.2010).
Related Posts Plugin for WordPress, Blogger...