Business-Driven OR Fact-Driven Design

It’s not always the technical reasons that drive the design decisions. More often, they are business based too. 'What design decision are you making' should also factor in 'When are you making the decision' and 'Why are you making the decision'. This is one of the areas where an experienced project manager or an architect can guide their technical teams in making those right decisions - means just right for the time and the context. This is what we can call as a Business-Driven-Design or a Fact-Driven-Design.

There are two extremes as far as our approach to design is concerned:

Piecemeal Approach - Not paying enough attention to design and writing code on a piecemeal basis. It can be due to lack of necessary technical expertise or due to high misinterpretation of the Lean Development concept and thus making it more leaner than it has to be.

[This leads to highly unmanageable and poor quality code and will have impact during and after the development cycle]

Best Design Approach - Trying to apply everything you learnt about 'Software Design' and 'Design Patterns'. Well, I was not an exception here. :)

[Possible under all imaginary and ideal conditions like - you have unlimited time OR you do everything right to the perfection the very first time. Practically, it is never possible.]

Common sense and business sense play their roles in coming up with a design that is ‘necessary and sufficient’ with reasonable trade-offs made. In other words, it is about the art of looking beyond your code. 'Trying for a right design at a wrong time or for a wrong reason may turn out to be more dangerous than a poor design.

What-to-do?

Invest in better design only if it is necessary and only when it satisfies the simple rule of ‘Return on Investment (RoI)’ .

For example, assume you are developing a tool for some kind of Tax Processing requirement, supporting two different Tax Implementations, say Sales Tax and Corporate Tax.

-- If you are sure that no other tax types will be added in future, do not try to get the best design in terms of abstractions and reusability. It is not necessary though technically right. Handle them with simple if-else logic wherever you can, after having just-sufficient abstractions and reusable code implemented.

-- On the other hand, if you know there are going to be multiple other tax types supported, handle them better in terms of design. It is technically right and necessary as well. Even, this helps you make right decisions on all other connected things like whether to use a radio button or a drop-down box for selecting the Tax type on the front-end.

When-to-do?

• Temporary trade-off

For example, if you are about to make a code drop and you have noticed a 'non-trivial but useful' design change to be made, do not handle this in haste. Your decision might be right, but not the time. Rather, push this to the next iteration, probably as a first things to do.

• Permanent trade-off

For example, if you are product based and your eye has caught a design improvement to be made right before a release, let the technical guy inside you sleep for some more time. You are too late, though you are right. The best design 'now' is the design that is already working. This is where ‘Don’t change working code’ makes sense.

[If the impact is significant but not severe (like a typical performance issue), it can be handled in a follow-up release.]

Why-to-do?
It is mixed with what-to-do and when-to-do.

-- Why do I need to design this way or that way?
-- What is the benefit for me or the impact on me during the development cycle? (Well, it is not about your performance appraisal and pay hike. :) )
-- What is the value/impact for the customer after the delivery?

If you don’t have enough time or enough data and you have to choose between 'better design' and ‘working code’, it makes perfect sense to prefer the latter. Spend the time you have for doing better things like - testing your code properly and fixing any potential bugs.

Are you making the right design decision (to-do or not-to-do) at the right time?


Are you considering the 'value proposition' in making the design decisions?






(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)