Chris Donnan : Programming – Brooklyn Style


Amazing Test Automation

I was reading an article about how Google is going to start releasing versions of it’s browser every 6 weeks – much, much faster than it’s competitors (Firefox, IE, Safari). They have the same goals I do in my day to day job – deliver faster with fixed quality. HOW !??

Google is serious about test automation:

  • Runs 120M individual tests / day
  • 1,400 continuous integration builds
  • 65K builds per day
  • 6,000 developer / 1,500+ projects

That is serious scale and commitment to test automation. This is the only way to go fast at scale – full stop

Filed under: Agile Development,unit testing — chrisdrop @ 07:33


Agile on Wall Street

In this article of Wall Street and Technology’s latest issue they chat about how so many banks are looking @ Agile methods to deliver software. David Chapman, one of the partners at my former firm is one of the main interviewees. He talks about the issues with CMM based methods and how agile is different. They also mention how Finetix was bought out by Sunguard.


Filed under: Agile Development,programming — chrisdrop @ 13:10


Certified Scrum Product Owner

This morning I got a message from the Scrum Alliance folks.  I got my “official” Certified Product Owner info. The course was a good one. Mike Cohn and Ken Schwaber have been getting firms running using scrum for a long time. I have done it for some years – but their experience was extremely helpful. They were happy to answer any questions, specific – hard ones.


Good stuff. Even though I have been doing it for years, I still recommend a formal effort for anyone practicing scrum.


Filed under: Agile Development,programming,scrum — chrisdrop @ 13:22

Hysterical ScrumMaster pictures

I thought this was particularly amusing. I am a huge scrum believer. I am also responsible for promoting scrum within my organization. I really, really believe in it – really …. BUT … The terminology is sometimes hard to get over for people. I thought this pic was really – really funny :)


Filed under: Agile Development,humor,scrum — chrisdrop @ 13:08


Certified Scrum Product Owner Course

I am happy to be going to a Certified Scrum Product Owner Course this week in Boston. Having done the scrum thing for a number of years now, I am looking forward to speaking with and thanking the 2 people giving the course Ken Schwaber and Mike Cohn.

Ken Schwaber is one of the folks to really started scrum. Without Ken’s writings and efforts – many more of my projects would have been less successful. Scrum has been a key part of my software belief system for some ~4 years now.

Mike Cohn on the other hand has had a profound impact on how I have been doing “requirements”, software planning and estimation. I look at Mike’s work as a sort of 2nd generation of stuff on top of scrum. Mike’s work in using user stories as the product backlog has been instrumental in how I view “requirements”/ feature management – product backlog development. This set of work has built upon the initial “scrum stuff” in a way that has really helped deliver software.

This particular course is focused on the product owner role. I have been spending lots of time “getting together meaningful product backlogs” for all of the teams moving to scrum at my current firm. It is an interesting effort and challenge. I am also trying to coordinated stuff between multiple product backlogs, deal with lots of “technical focused teams”, “infrastructure teams” etc. In a big firm – there is a lot going on! It seems this course is right in the space I need some extra guidance. I think I am aware of all of the writing, newsgroups etc – and these resources have been extremely valueable in going about my business. I have all of the “textbook answers” – now – where the rubber meets the road in daily life – any extra guidance would be great.


Filed under: Agile Development,scrum,Software Project Management — chrisdrop @ 13:51


More on plinko style architecture – how do we do architecture?

In a prior post I talked about how important it is to “slice the work vertically” and not to get lost in BDUF land. In general, I think architecture needs to be “right sized” to the project. A teeny app needs little or no real “architecture planning” a huge app certainly needs some. The trick is not to think you can do BDUF for real, you just hide work and make the other BDUF believers “feel comfortable”.

I am certain in my current role that people think I am “a classic agilist” ready to run off and work with no longer term vision, plan, agenda. If we do that, we will surely get into a bad place is the criticism.

  • I believe that NOT writing tests
  • Not acknowledging technical debt and addressing it
  • Not time boxing
  • Delivering infrequently to the cleints
  • Inexperienced developers/ naieve assumptions

These are the primary things that make you “get in a bad place in the future”. Certainly – refactoring on the enterprise scale costs lots of $ as you are forced to change lots of nodes/ components/ layers. Limiting the scope of refactoring is very important at the enterprise level.

Blah, blah, blah – so what is this architecture business and how do we do it? I have been using this simple model:

The plinko architecture formula

  • Prior art (someone did something like this in the past)
  • Vision (if we had this XXX, then all these other problems would go away)
  • Collective experience of the team
  • Well known components (we KNOW we will be using our corporate XXX service/ component/ etc)
  • +
  • Development Spike (time box, rapid prototype 10 ways to solve each problem)
  • =
  • “Ballpark architecture”

This set of stuff defines the “buckets” at the bottom of our “plinko board”- our “ballpark architecture”. We then take our features and while we implement them, we let the parts of our solution fall into our architectural buckets. This lets us have a set of basic working models, yet our architectural implementation evolves alongside the actual problem, not in a silo!!!

I am a HUGE believer in “co-evolution” of frameworks/ architectures evolving WITH the problems they solve. Building entire frameworks and architecture models detached from real problems just delays the learning. You learn on the day you start to USE the framework/ architecture model where you were wrong, what inconsistencies you have and what you REALLY need.

So – my 2 cents is – do not build in a silo. Use the Plinko architecture formula above for your basic architecture approach….


Filed under: Agile Development,Developers,programming — chrisdrop @ 10:31


Conquest through extreme composition + glue, Part 1

We are currently in a 2 week design spike. We are developing a solution with one primary goal:

Integrated User Experience

The product will be used to unify many .net based applications. The product must enable developers to deliver faster than ever to their trading clients. The product must provide radical levels of integrated user experience. We must go far beyond our simple “plugin model” if we are to provide the ability for peer plugins to be themselves extensible, for the host application to be itself extensible and for all participants to get maximal reuse.

Amidst the course of this spike, we are all coding a lot and talking a lot. The team has lots of smart folks with a collective ton of experience building desktop applications serving the hard demands of traders. We are trying hard to keep our deliverables “end user effecting” yet during the spike, we are basically focused on defining a basic set of architectural buckets (see plinko model) into which our end user effecting features will fall during implementation.

What do we really want?

  1. extensibility/ plugability
  2. reusability
  3. testability

I think the crux of it is:

  1. Really practicing composition
  2. Really practicing The Dependency Inversion Principle
  3. Sticking stuff together contextually – some glue
  4. … sort of an afterthought … Getting away from too much procedural programming hiding in OO code.

That is really it. We want to rely on abstractions and not know/ care about what our implementing parts need to have in order for them to work. We want to support The Open-Closed Principle by varying the behavior of our system by providing different collaborating implementors.

I am trying hard to help a lot of folks understand the need for The Dependency Inversion Principle. I am trying with step by step success to move lots of folks to really writing unit tests. I believe this:

  1. You start writing unit tests
  2. You earn the understanding of why you need The Dependency Inversion Principle
  3. You practice The Dependency Inversion Principle
  4. You get more adaptable software that is composition based
  5. You earn the problem that spring and other dependency injection containers solve – the need for “formalized glue” to stick everything together.

I have seen this evolution time and time again. In stead of “ramming this all down people’s throats” – I try to let people “earn their next problem”. As soon as people earn the next problem, they see the value of the solution at the next level.

Anyhow – this bunch of stuff says, ideally you are:

  1. Relying on abstractions
  2. Allowing your implementors to be given to you in stead of newing your concrete dependencies

Your abstractions typically have N implementors – a bucket of IThingable’s are available. This is plugability - the reliance on an abstraction and the ability to “inject” something along that seam. The isolation factors of The Dependency Inversion Principle gives you the testability. The fact that you have buckets of things that can be implemented at a level of abstraction + composition gives you the reusability.

This gives us a picture that looks like .. coming in part 2 :)

Filed under: Agile Development,Developers,programming — chrisdrop @ 16:23


The Plinko model of software architecture

In general, “architecture” is a word that carries some heavy connotations in the “agilist” community. We all fear the unfortunate problems that BDUF brings with it. We do not believe it is wise to start off by defining a big detailed design up front. What happens is that once you begin the learning (working) process, your BDUF plan changes anyhow, often A LOT. In this case you are either forced to

#1 Change your BDUF substantially enough that it was a waste of time.

#1 Conform to your BDUF even though it is no longer fit for the work you are doing.

Neither of these things is particularly nice. The agile view is that you let your architecture emerge. You put lots of tests in place, and your system is rapidly changeable. This is all well and good, but the larger the systems get, and the more dependencies there are, the larger and larger the “rework” becomes. For truly non-trivial distributed systems of applications (enterprise application portfolios for example) NEED some contracts between them. The volatility INSIDE one of the specific systems can change a lot easier than the contract that a system has with the systems that depend on it.

The general idea with “architecture” is that for small systems, you need a little, for medium systems, you need a little more, for large systems… etc. You DO want to allow the architecture to emerge, but you also need to coexist in a network of dependent systems. What are we to do?

I will add one more dynamic to the mix. In general, you want to be oriented to delivering “end user effecting behaviors”, not “software elements” per se. The general idea of “slicing the work vertically, not horizontally” has been spoken about a few times before, and it is something that I preach all the time. The basic idea is that you DO NOT want to build your system layer by layer, then arrive at the “end” or “top layer” and finally see it all come together. This is a model of failure for several reasons:

#1 The vaporware problem. Long periods of time pass and you have “vaporware”. You may well have developed a great resource access layer, transports, middleware, etc., BUT if you do not have anything visible and meaningful to an end user – it is STILL vaporware.

#2 When you get to the top layers, you get the fun of seeing the “things you missed” that you need from the upper layers and these changes have to ripple back down anyhow (aka, you were not really done with those lower layers as you thought). This leads to “hidden work”. “I thought we were done with the DAO, why do we keep going back to it”. You have a fake understanding.

#3 You get to see the incongruities between layers later.

#4 You are getting feedback from end users later. You are learning later.

In stead, we slice the “work vertically”. We in stead focus on delivering “user stories” or end user effecting features. We then work on the parts of the system that we need to in order to meet this goal. In this model, we are able to get feedback and learning faster. We are able to evolve the architecture each iteration. We have emergent architecture behavior. We are able to focus on “the prize” that really matters – delivering end user functionality.

OK – sounds good, but what does this have to do with Plinko and architecture? In case you missed “The Price Is Right” era; Plinko is a game that looks like this:

The basic idea is that you drop some disk like thingys in the top, they sort of “plinko” their way down into some predefined buckets at the bottom. Lately I have been using this game as a sort of metaphor for how I have been thinking about software architecture these days. The applications/ ecosystems of applications that I have been working on are large. Investment banks have very very large interconnections of software that is related, codependent, etc. There is obviously the need for some level of architecture. We ALSO want the emergent architecture behavior. In order to reconcile the 2 models, Plinko makes a lot of sense to me.

The basic idea is that your architecture is the buckets at the bottom. The implementation of work items – that are “vertical slices” are the bits and pieces of development along implementing a story that “plinko” down and land in some predefined bucket. People working at levels that cross between systems, on system integration/ collaboration, internal service providers, API providers etc work to define the “buckets” that make sense and provide a basic framework for operation. The best case is that “scrums of scrums” collaboratively evolve the “buckets” of the “grand organizational plinko”. This is real work and there are non-trivial challenges to effectively doing this work. That being said, the idea is to focus on true “breadth” here. The higher level architecture definitions focus more on defining the buckets than worrying about the “depth first” implementation of any particular bucket. The implementers of any particular bit focus on delivering those vertical slices and letting them plinko to the correct place.

We allow our development teams to focus on iteratively delivering “end user effecting features” or stories. Their ability to deliver these is the primary measure that matters. Tested delivered features is all the business really cares about anyhow (yes, quality, fitness for purpose, etc., but basically that). The implementation level inside these buckets emerges. Things that seem to fall outside these buckets can work to evolve the more “macro” level archetecture. In the “scrum of scrums” model, the bucketing of the plinko board can certainly change, but these changes must make it onto the queues of work for any of the players/ teams.

The key here is to work on defining the buckets, but not getting too caught up in immense detail. Things WILL change. Too much definition of detail will be false anyhow. Setting up an architectural model that expects change and allows for implementations to drive the changes as needed is required. The end effect is a system of systems that can co-evolve. This is the real end goal. Building large class software is a challenge. BDUF does not work in general  – the learning that happens during development will change your design. Short sighted design decisions can hamper sustainability with zero design/ architecture. The Plinko Model allows for a bit of both, while allowing teams to “slice the work vertically”.

I’d love to hear any thoughts :)


Filed under: Agile Development,programming — chrisdrop @ 18:01


Test Driven Development and Mock Objects Developer Session Slides

Here are some items from the Test Driven Development and Mocks developer session I did a few weeks ago in NYC. I excerpeted lots of people -see the refs at the end of the slide deck. The main things I wanted to hilight were #1 – how important unit tests are. How much better they work when they are done with other core development practices (IoC, etc), How useful mocks are – and a core mock pattern to use.
TDD Dev Session.ppt


Filed under: Agile Development,java,programming,User Interfaces — chrisdrop @ 19:00


Test Drive Development Developer Session – Unit Testing and Mock Objects in .Net and Java

It is time for the next ‘Developer Session’ in my series … The last one that we did – Spring Framework Developer Session (code, power point) was a hit – with maybe ~40 people who came out to hear about Spring. I am happy to report the next dev session is:

Test Drive Development Developer Session
NUnit, JUnit; Rhino Mocks in .net and Easy Mock in Java

Tuesday July 25th 6 – 8 PM

228 East 45th Street
6th Floor
New York, NY 10017

These sessions ARE OPEN TO THE PUBLIC – There is a snack before we get into it – then a presentation, demos and questions.

The sessions I have planned remaining are :

The Peer Frameworks Series – .Net and Java

3) Db4o Developer Session – Open Source Object Database in .net and Java
4) ORM Developer Session – Hibernate, NHibernate / IBatis

I will update the agenda as we finish planning it in the next week or so. I hope to have dial in access for people that want to dial in – and ideally a ‘webex’ type access as well. Feel free to contact me with any comments or questions. Also please message me to let me know if you want to attend – here This will help us plan food, chairs – etc.

I will be focusing on:

Rhino Mocks
Easy Mock

My Best;

Filed under: Agile Development,java,unit testing — chrisdrop @ 03:53


Get rid of your code – 37 Signals “Get Real”

Here is a GREAT quote.

If programmers got paid to remove code from sofware instead of
writing new code, software would be a whole lot better.
-Nicholas Negroponte, Wiesner Professor of Media Technology at the
Massachusetts Institute of Technology and founding chairman of MIT’s
Media Laboratory ( from And, the rest of the (AIGA Conference) story)

Based on all the code purging that a particular collegue of mine and I have been doing lately – this quote just stood out to me. We have been throwing out the bad, ugly, marginal etc – in favor of LESS code – done better.
This quote is quoted in 37 Signals (of RoR fame) Get Real – interesting read moreover. It covers your basic agile principals – just not really branded as ‘agile stuff’ but 37 Sigs general guide to success developing WEB APPS.  This PDF only book generally describes how small teams, delivering iteratively, being lean can do well. This is the agile song – said well by a good group of guys. I give Get Real the thumbs up. Nothing revolutionary – but it is a decent read.

Filed under: Agile Development,programming — chrisdrop @ 04:11


Pragmatic Programmers 10 Part interview

Here is a link that has all 10 parts of an interview with the Pragmatic Programmer guys. I refer to lots of these ideas all the time. So – go read this stuff – better – get and read the 1st book The Pragmatic Programmer: From Journeyman to Master

Then get this one and read it: Ship it!: A Practical Guide to Successful Software Projects

Then if you like Ruby – get these – Programming Ruby (2nd Edition) and Agile Web Development with Rails: A Pragmatic Guide

I guess I am a fan of thier work – lol.


Filed under: Agile Development,books,programming,ruby — chrisdrop @ 16:00
Next Page »

Powered by WordPress