How to convey the importance/role of application architecture to business heads & junior developers.

Question

Hi there, This question is subjective and can reasonably only be answered by those seasoned developers with leadership experience and management personnel with a sound technical proficiency.

For the past year I've pursued educating myself extensively in OOD to become a stronger programmer. In particular, reading and applying knowledge attained in SOLID priciples and Domain Driven Design - understanding industry best practices and essentially "refactoring to patterns".

I'm 25 and work for a rather young company whose development team is around the same age if not younger. Although I've much to learn, I've taken what I've gained from the writings of Robert Martin, Eric Evans, Martin Fowler, Tony Sneed, Julie Lerman, Dino Esposito, and a host of other phenomenally brilliant and talented programmers / bloggers (to whom I'm ever grateful), and have begun to incorporate these concepts at work.

I'm well aware of the hazards of over-complicating a design and criticisms towards architects who remain perpetually designing for business requirements which don't exist. YAGNI! Or as Joel Spolsky calls them architect astronauts.

My question is one I've yet to find much information on and I will get to it in just a moment. The company I am with has been virtually exploding in growth. The development team consists of young guns fresh out of college, as are our project management. The developers have little to no knowledge about design patterns, or N-Layer architecture in general. Our code simply consists of "Spaghetti with Meatballs"... the meatballs being domain-like classes living within an App_Code folder. There is no separation of concerns, with nearly all business logic being done inside code-behind files and "meatball" classes.

The developers/management have all looked to me to provide guidance in going about re-structuring our development practices, however, as those with N-Tier experience know - there is no one golden solution to fit every business model. I've tried explaining the different facets to the makeup of DDD and what each part's functional purpose is to our developers. It was impromptu, yet they were able to come away with a general understanding of the different pieces in play but not how to implement them of course.

In a few weeks, I would like to start giving continuing educational in-house speeches. Most involving just the dev-team, but also project management and our CEO; who plays an intricate role in the life-cycle process by allocating development resources and deciding feature sets. It is here which I am rather unsure how to proceed...

How do you convey the long term benefits of applying an architectural framework to non-technically savvy personnel or developers with little OOD experience?

How do you illustrate the costs for maintaining a poorly written software will eventually hamper product development 5 years down the line?

Applying domain driven principles will NOT help the company see another dime in the short scope of things, but will allow for application extensibility; how do you explain extensibility in terms of business, not code?

We currently have problems with "feature creep" in our agile iterations. Design is always pushed into the background "if there is time to clean up later". And we are at a point in which future plans for the software incorporate a SOA.

Much thanks in advance and sorry for writing an essay! I hope the development community finds this useful.

I've tried to create a basic illustration for the team to visually see what one example of a DDD application might comprise of. I have left out other key elements including Service Locator, Unit of Work, State Management, etc on purpose. Many of the aspects pictured are not required or can be added in time.

[EDIT]

I should note the following:

The company, like any young expanding enterprise is going through growing pains ... which is a wonderful thing in business. Please understand this as resources are not unlimited and development iterations are highly dependent on client needs and feature sets. What I'm ideally looking for is others who have experienced similar situations where they had to find a balance in continuing down a development road led by sales - which would knowingly only lead to product instability, and that of veering a new course of re-factoring and implementing new design.

Answer 1

You don't. Do you expect your plumber to explain the intricacies of his craft to you when you hire him to do a job?

DO NOT attempt to explain those concepts to management, and NEVER EVER show that diagram to them unless you want to put them to sleep (best case). Worst case, they will think they understand it and will start making "design decisions" that they really aren't qualified to make - but then you have to do it that way because of their "political" position in the business.

Management and business folks are usually more interested in "how long will it take" and "how many people do you need" to make it happen - businessy stuff. Give good estimates and deliver on schedule and they won't need more - that is why they hired you (and experienced project managers etc.).

If you are in a position to do so, write up a simple & general set of guidelines for the new coders to follow and arrange your work flow to make sure an experienced developer/designer/architecty type writes up or at least "signs off" on the tech specs for new features / products to make sure they follow the chosen design/pattern model.

You can certainly train the newer developers about the important design concepts, but you need to get code out the door too. It's much easier to give them a spec tailored to design model you want to implement so they get some "hands on" experience with it first before discussing it.

Answer 2

I would add that reading stuff in a book and applying it are two very different things. Books inevitably use simplified examples. Given that you are 25, and you sound well read and bright, you may recognize the value of persuading management to bring in an old experienced hand.

Balancing design concerns is hard. Balancing design concerns for the first time is really hard. Balancing design concerns along with management and personnel concerns for the first time is almost impossible. You're leaving yourself with almost no room for error on many fronts which you don't have experience in.

I would suggest asking for someone (like a Project Manager) to help you whip people into shape, or an architect-type to provide some guidance. Ask for someone who has 10+ years in their field, either as a consultant/part-time or full time, because it sounds like you're in over your head...

Answer 3

You will need to take separate approaches to explain your vision to Management and Developers, they are two different cattle of fish.

To Management, I would suggest you use common term such as ... we are dividing the tasks into building blocks, each of the block is reusable, manageable and discovering risks(issues) upfront. Future changes/enhancements/product evolution, can be acting on the one or more blocks hence efforts and risks are localized. Don't go into technical details unless you have to or are required to.

To Developer, you will have to run a simple workshop and draw some statistic or examples from software engineering book and I'm sure they have all heard or read about fixing software cost far less during earlier phase than in implementation. Clearly articulate the motivation behind the architecture and give simple example that they can relate too. Similar language that they use in design pattern book such as motivation, intent, scope and etc are good starting point.

Answer 4

How well could you articulate the problems with the current codebase? How well can you say, "This is causing us a lot of pain!" and other notes to voice why you'd want to bring OOD into the picture here? That'd be my suggestion for a starting point on how to sell this, assuming that is really what you are asking here.

Are you planning on trying to steam roll in these changes or gradually introduce them and see what works and doesn't work? That's another aspect as if you try to change too much too fast, you'll just hit a big wall of resistance. While the idea of technical debt may sound simple enough, it isn't necessarily something for management to really get on the first try at least to my mind. I'm sure there are other terms besides technical debt that may work and you may have to do some digging to find ways to describe why there should be some time spent cleaning things up and preparing for the future in a sense though hopefully it isn't too tough a road for you.