Blog

Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.

As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.

Here I list the ten most important reasons that I believe make design absolutely indispensable.

1. Increased costs are just an illusion

Costs of design are substantial. Yes, it does cost you (and your customer) time and money to properly do all design work. However, this cost is only an illusion, because costs are way higher if you don’t do design.

The point of designing (one of many points actually) is to detect any possible defects in your solution approach. Things like missing requirements, or like incorrect classification of a gap as a fit. According to McConnel’s legendary Code Complete, if you introduce a defect during requirements analysis (e.g. wrong requirement), the best time to detect that mistake is during requirements analysis. If you detect that mistake during design, you’ll spend three times as much time to fix it. However, if you skip the design altogether, and just jump into development, fixing that defect will cost you on average between 50 and 100 times as much time. Time that you could have saved investing only a fraction of that time to design the thing properly.

Furthermore, if a bug is made in development, fixing it during testing will cost you 10 times as much as fixing it during development. Fixing it during production will cost you up to 25 times as much time. Without proper design, there is no easier thing to do than introduce bugs. If you don’t know exactly how something should work, what are your chances at guessing it right. How often did you just hand requirements over to a junior developer. It’s not their fault for making a bug, if they didn’t have a blueprint.

So, as I said, costs just seem higher, because of the design, but in fact, they would—sorry, no—they WILL be much higher if you just skip it.

And it’s not only about introducing bugs.

How much does it cost to reassign a developer from an ongoing project to fix something free of charge for a previous projects?

What’s the price of an unhappy customer?

2. Selecting the optimal solution

Okay, so you have very competent developers. World champions. They know their C/AL and C/SIDE inside out, and they rarely produce any bugs. That don’t impress me much.

Are your developers also the best-in-class application consultants which will be able to come up with two, three, maybe more solutions, some of which completely standard, and then choose the best possible one?

When you have a hammer, every problem is a nail. When you give a requirement to a developer, what do you expect them to do? Well, develop it, of course. Maybe development is not the optimal way. As a matter of fact, development should be the last option considered. How many standard application approaches do you think your developer will consider before they open Object Designer and start coding away?

By giving a chance to a competent application consultant to consider alternative approaches, and select the best one, you miss probably the last opportunity to score a slam dunk on the first try.

3. Customer contribution is priceless

If you start developing before doing any design, when do you give a chance to your customer to review your design decision and agree that this is the best possible solution for them? Well, isn’t this the testing, isn’t that when the customer should say if it’s okay or not?

Um, no.

Design is split into two distinct tasks—functional design and technical design. When you do functional design, you only describe how functionality will work in a way that an average key user can easily understand how exactly it will work in the system. They can then quickly tell you if they agree to it, or if they believe it’ll never work.

You make a solution for your customer, and their contribution in design phase is priceless. When building a house, you don’t put a single brick before the customer reviews the blueprint and confirms that yes, that’s what they need. Delivering a dog house to a customer who asked for a house is just not going to work. Well of course, yes, technically, dog house is a house, but still…

4. Knowledge transfer between teams

If you want to be really successful at delivering projects, you’ll most likely have a separate support team, and a separate project team. In fact, you need completely different competences for support consultants, than project consultants.

When your project is finished, and you deliver it to your support team with compliments, how quickly will they stop calling you about resolving the problems? How quickly will they really learn about all the nitty-gritty details of your custom solution?

If there is no design documentation, this may even never happen.

If you have design documents, and if they are any good, you can just pass them on, and your support people should be ramped-up to support the new solution in no time.

There is no single more efficient tool for transferring the solution knowledge from your project team to your support team, than design documents.

5. (Re)use cases for design documents are abundant

Do your customers ask you for user manuals? Do you prepare test scripts which are followed during acceptance tests? Do you deliver some operation guides? How do you document your configuration?

I ask this, because it always catches me off-guard when a consultant tells me they are writing user manuals—and they all say they are useful—but the same consultants don’t do design, and don’t see much value in design.

Actually, writing user manuals takes about no time at all if you have good design documents. Better part of the functional design documents content can be turned into user manuals just by rewriting the cover page content.

Design documents are basis for test scripts as well. A well-written design document is three quarters of your user acceptance test script. Just add another column for OK/NOK classification and there you go.

Also, you probably do deliver some kind of configuration documentation. It’s an integral part of your design. Sometimes, for a functional requirement you don’t have to document more than your configuration decisions and setup choices.

All of these are examples of situations where you simply go and copy-paste your functional design documents without much extra effort. How costly and how pointless is the design work now?

6. Ensuring the system integrity

One of the primary goals of design is to ensure that system stays in a consistent state, and that process and data integrity is ensured. If you just jump into development and don’t consi
der all the possible consequences of your change, you might get a round-trip after a round-trip of debugging. Or you might get inconsistent data later in production.

Your developer might not be aware that together with that time attendance posting, they may also need to post some G/L entries. Or that some G/L posting routine should actually start from an item journal because otherwise you get incorrect item valuation results.

By documenting your design decisions and data flow, you are giving yourself a chance to think about it better, and also other people to contribute, especially if you also do a thing called design review.

7. Aligning competence with responsibility

Sure Step gives some good guidance about who should do what kind of work at which stage of translating requirements into functionality. By assigning responsibility just to a developer, you are missing an important point, which is competence. While your developer may be able to do the whole job, are they the most competent person to do all of it?

Having one all-rounder may be good on small-scale projects. But generally, an all-rounder will do a lower-quality job than two experts. I always prefer asking advice of a financial consultant, even though I can handle NAV finance management myself.

My impression, and please correct me if I’m wrong, is that NAV solution providers tend to generate more all-rounders than experts, and I attribute it solely to the fact that resources are most often not assigned based on competence, but based on availability.

Josh, the manufacturing consultant is busy so you assign Adam, the developer to a task. At the same time, Nancy, the finance consultant needs some development done, but since Adam is busy doing Josh’s work, and Nancy has been to the C/SIDE Development course, she takes on the challenge. Josh becomes available, and has nothing to do, so you assign him to work on a retail management project. You just never seem to have right people do the right work at the right time. And your only choice seems just assigning people ad-hoc. You generate inferior-quality work, at the same time you never really grow anybody into a field expert.

The more ad-hoc your approach is, and the less design you do, the more resource availability issues you’ll have. If you properly plan, you can always have your most competent people available for your tasks. And guess what, design = planning.

8. Better understanding of process and data consequences

Touching NAV without understanding full consequences of your decision, opens a door to many process flaws, data inconsistencies or errors, which are far worse than bugs. A bug is malfunction, where there was clear intent to get function. The code can function perfectly, without any bugs, but can still cause serious data and process issues.

For example, a developer was assigned to a request from an accounting department, that inventory should include all the internal quality control costs, and that inventory accounts must reflect this increase in cost. The developer develops a routine which posts these costs to proper inventory accounts, you test it with the customer, and figures work perfectly. Suddenly, the customer calls you with an issue that there are zero items in inventory, but inventory value is huge. You test, and make 100% sure that posting of extra costs work properly—so no bug here. And it’s not customer’s problem or developer’s problem that neither of them knew that value has to be attached to items in a far different way, than just posting something to inventory accounts.

Proper design, done by a competent expert, can reveal such mistakes, or avoid them in the first place. In the example above, if a financial consultant has first done a proper functional design, the developer would have known how to properly attach quality control costs to inventory value.

9. Ensuring the upgradeability and maintainability

While programming, if little attention has been paid to the design (i.e. how the development work would be executed), then it’s more likely that the solution produced will be less maintainable, and less upgradeable to the next version, especially if complex development is involved.

When complex customizations are executed without proper design, the solution will be mostly random, consisting of patches and fixes (which resulted from trials and errors) rather than being a coherent and consistent whole. Maintaining a series of patches is difficult and expensive, and often touching one of them, brings unpredictable consequences on some others.

If more people are involved in maintaining a solution, and the solution was coded without design, if Rick adds three fields, four functions, and touches fifteen triggers in a table, and messes up a form, and then Frank has to maintain it—the likelihood of Frank knowing what those fields, functions or triggers do are virtually non-existent. Instead of tapping into existing functionality, he can add more and more fields and code, generating a lot of redundancy, not only in solution logic, but also in data, which results from usage. I once reviewed a project, where 18 developers were coding around the clock on word-of-mouth requirements directly from the customer. A nightmare. On Elm street.

Upgrading a solution like this is next to impossible. If you have tried, you know. If you haven’t, just trust me on my word—I have.

And guess what? When a solution is unmaintainable, and unupgradeable, customers will eventually give up on it. Instead of investing into a new version, sometimes it just makes much more sense to just throw everything into a recycle bin and start with something new and better. And guess how likely it is they will choose you to do it for them, again?

10. You always do design anyway

And finally, believe it or not, even if you think you don’t do design, you still do it. Think about it. Reading a requirement “a sales order must be tagged with priority”, and translating it into a new field called Priority in Sales Header table, is actually design work. As informal or undocumented as it may be, your understanding of the requirement and translating it into a need to create a field is pure design work.

This was a simple example. Take whichever complex requirement you have, and code away. Um, you can’t, actually. You’ll spend at least some time thinking it, and rethinking it, and if you didn’t spend enough time thinking, you’ll spend a lot of time fixing the code, and scrapping it and starting from scratch. The point is: thinking about the solution IS designing it.

Once you reach a design decision in your head, how much extra time does it take to formalize it into a design document? I’d say, not much. If you use proper templates (such as those coming with Sure Step), formalizing the design isn’t too complex or time consuming. Yes, it often takes as much time to formalize design into a document as it takes to develop the feature, but with all other reasons above, any time you spend in formalizing the design is time well invested.