Blistering Pace Development using: DDD, DI, AOP, AGILE and some CLEAN CODE

I recently managed and jointly developed a system which evolved into the culmination of several methodologies and practices. We were severely short-staffed being a band of 3 and weren't the strongest technical team either.

Managing this group proved to be a challenge, and i had to pull out a few improvisations and tricks

to get the team to work together effectively and efficiently. Being a true techie at heart, management is the last thing i prefer to do, yet the team decided i should ... and i was dubbed.

We chose to follow the ICONIX process, which proved to fit in well with achieving a domain-driven-design.
More disciplined than XP and in some cases reminded me of my Waterfall experience. Yet very iterative in nature and yet we were able to produce a system at a blistering pace.  Needless to say this post will be on my reflection on our technical achievements while understaffed and not on any particular process.
I'm convinced that a process is not a SILVER BULLET at all, in fact i believe a process should only facilitate the quest a team decides to undertake. I'ts like an adventure with Robin Hood or the Three Muskateers,
you decide which road to undertake, the process only facilitates to keep marble under your feet.

The first essential component to speeding up development was to understand the problem correctly.
Placing things into context and building a common understanding of the problem with your client was
the first requirement. Below is an excerpt from a write-up I recently made ... i added it since it captures
the gist of what i think a DDD should accomplish.

"In the pursuit of a proper solution for a problem, the problem to address needs
to be understood correctly and thoroughly. An incorrect comprehension of a
problem domain could degrade an otherwise elegant solution to become substandard.
Consequently, placing software requirements in context of the real
world is an essential exercise.
By expressing real world phenomena within a software application itself not
only aligns it closer to the needs and requirements of a client, but also assists
in the establishment of a ubiquitous language amongst different stake-holders.
A software construct not only communicates directly to a machine, but also
serves as a platform for communication amongst developers and future maintainers
of a system. A software construct that utilize a glossary build from an
established ubiquitous language would not only serve its purpose as an interface
between developer and machine, but also increase effective communication
between developer and client." - Michael (2010)

The second requirement to achieve blistering pace development was to establish
similar collaboration and mutual understanding amongst the team members. Sure
enough a DDD will assist, but more is required. A common understanding of high-level design and
architecture keeps everyone in the loop. We have vision, we all know where we're heading.
A visual representation of your vision whether it be an architectural view or a couple of robustness analysis
diagrams stimulates creativity ... put your PC aside ... to achieve a great design requires lateral thinking
and developers that are kept in the loop. A developer's feedback keeps everyone in touch of technical
feasibility and estimates (some design might be easy for us to implement, it does not however imply that the individual tasked with that design would find it easy... u need to put design in context of technical abilities).
A complex design might be highly modifiable and flexible, yet a simpler solution
could take far quicker and easier to accomplish technically. Yes we all know developers can give
management the moon, however that doesn't imply we'll have the moon ready for you next month !!
My answer, cut off what you can early on but don't neglect the domain. Whatever you do above all else,
 KEEP YOUR DOMAIN LAYER UP TO DATE !!!
Tackling business complexity is highest priority, technical extensions are easy to add later on. Of course establishing a commonly understood technical language by naming new design patterns and old ones alike, assist in establishing a ubiquitous "techie" language.

The third requirement to achieve blistering pace was to streamline technicalities.
Infrastructure and interface code we've all written over and over and over again. Surely we can encapsulate that recurring pattern, it will save soooo much time. My answer to this is the culmination of frameworks, dependency injection and aspects. Choosing your framework is critical, don't fall into a trap hole.
Some frameworks give excellent speed-ups at first but severely limit flexibility later on.
IMHO a framework should provide support for some kind of DI though. Delegation and strategies are just so much easier to accomplish using DI, and the best part is that it keeps code clean, which of course is my next point.

Writing clean code is essential to increase maintainability and progress. A code base that is self explanatory is much easier to follow and extend than a mesh of spaghetti. By avoiding puddles of mud you save multitudes of wasted brain cycles trying to grasp context of surrounding code, and facilitate focus on expressions of system behaviour instead.
Aspects is an effective way to delineate boundaries and enforce code policies or conventions.
Why use static analysis tools in a continuous integration system while you could have prevented it @ code time using aspects instead ? Time savers like that and pragmatic approaches to solving difficult hurdles just help so much in the long run. Of course one should not neglect conventional tools and methodologies like continuous integration, test driven development, test \ production environments, effective development environments (IDE, screen multiplicity, pc performance, spreadsheet timers, build tools and so on etc. etc. etc. they all assist to speed up development bit-by-bit. Standardization on tools also help, but watch out not to stifle creativity in the process. Too much red tape is not a nice atmosphere to work in (well that's valid for me, others might experience it differently).

And then there was the final ingredient required for achieving blistering speed. I know this post shouldn't be about the process, but yet it's so crucial. A great process applied incorrectly steers you off the marble road, instead of keeping you on it !! I would group the chosen process, the technical abilities and skills of the team and the developer-client relationship into a big bag called the X-Factor. Why do i do that ? Well everything in this bag depends on everything else. You see, it all depends, and it's an art to establish which process would fit your circumstances and which not. Sure enough you could have on your team one or more star programmers, but there's not such caliber of highly skilled developers lurking everywhere and on every corner. Besides, what are the odds that your entire team consists of gurus and you've got this great big budget to support your adventures. Well if you work for Apple or Microsoft, maybe, but for the rest of us you'll need to improvise, adapt. And that's why i'm not going to go into detail with this last requirement ...

And those are the things we did as a team. It worked out very well in the end and the exercise was extremely productive. I'm not advocating that an iterative process and a pragmatic approach toward effective
development is the conclusive answer for shipping products faster, but i think that all these elements are essential in achieving that purpose. With a thorough understanding of the problem, by avoiding analysis paralysis, improving team communication and effectively modelling the business domain did speed up delivery manifold in our case.

Anyway, that's my post for July. Been a while but at least still alive ;)