DDD

DDD10 - September 1st 2012

Richard Dalton

Richard Dalton started working  as a freelance programmer and mentor in 1996. In 2011 he finally got a real job with a trading company in Dublin, Ireland.

He has worked primarily in the financial and manufacturing sectors in Ireland and the United States, and has also lectured at both Griffith College Dublin and Waterford Institute of Technology.

He wrote his first program at the age of 10.  At 6 loc It reflected his passion for very small apps with with a very specific responsibility. Sadly it also contained both a GOTO and an Infinite Loop.

10 PRINT "tick"
20 PAUSE 50
30 PRINT "tock"
40 PAUSE 50
50 CLS
60 GOTO 10

Sessions Submitted

How to build a framework, and why you almost never should

You're four months into a three month project, you've produced some of the best code you've ever written, but the client has yet to see a single piece of functionality that means anything to them.

You're building a User interface for your latest project.  You've created lots of abstract Views, Widgets, Windows and Plugins, but nothing that looks like the system you're supposed to be building.

You used to be able to load and save data with relative ease, but lately find yourself spending more and more time trying to make your Persistence Framework work correctly.

Frameworks are wonderfully useful, they are challenging to build and insanely difficult to build well, and that's why clever coders can't get enough of them.  As developers our minds naturally wander to thoughts of abstraction, and reuse. Frameworks seem like the logical destination for that train of thought.

But, there's a dark side.  Messy edge cases, shoehorning of new code to fit existing frameworks, wasted hours working on the framework itself rather than actual paying projects, faulty assessment of effort, and return on investment.

We've come through something of a framework bubble.  There's a growing realisation that most frameworks don't just fail to live up to promises of increased productivity, they can actually have a huge negative impact on projects.

In this session we'll look at some of the challenges to building a good framework and the techniques and patterns that help meet those challenges.

More importantly we'll try to cut through some of the myths about Frameworks and take a cold hard look at the real cost of developing and using them.

 

The Tests ARE the Requirements

There's an old saying, "A man with two watches never knows what time it is".  In software development we typically wear at least two watches in the form of Requirement Specifications and Test Plans.

In this session we'll look at the wasted effort of keeping both Requirement Specs and Tests around. We'll examine the changes in team dynamics when we streamline the process.

We'll also look at the optional extra step of automating some of the tests.  We'll use FitNesse to demonstrate an "executable specification", however the specific tools used will be less important than the central message of the talk. 

Latest News

    DDD10 Site goes live

Sponsors

  • redgate
  • Gibralter Software
  • Developer Focus

Photos