IT:AD:Design:Concepts

(UP)

## The Design Process ##

Interview with Jonathan Ives
- Designing the 'back of the drawer'.
- Using an exclusive few at firstg, to create and develop a new language to descrive a new idea. Then getting a team to discuss the new idea, in the the new dialog.

Summary

I took this one from: Avoid “Good Ideas”

The really insidious thing about “good ideas” is that they are “good.” Everyone can recognize and reject “bad” ideas out of hand - It’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.

In other words, think if this is actually necessary or is it just feature creep. Software complexity increases exponentially so having twice the features makes the code complicated by much more than twice.

“Nothing is more dangerous than an idea if it’s the only one you have.”

S

rc: Pragmatic Programmers. Emil-Auguste Chartier.

Consider the decision you’re about to take. What will it cost you to change it at later stages of the project? Can you defer this decision? If you’re not sure about the decision, can you design the system in such a way that changing it later will not break things and cause unnecessary work?

Don't Repeat Yourself

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Src: Pragmatic Programmers

Modularity in software is important. How independent is this module or block from other parts of the system?

Testability depends on modularity, complexity, code style. Don’t neglect testability of your system or code.

Because architects tend to immediately enter problem-solving mode, we forget, or rather have never learned how, to interrogate the problem itself. We must learn, like a telephoto lens, to zoom in and zoom out, in order to ensure the question is really framed properly, and that we’re not merely accepting what we’re given.

Instead of immediately working to solve the problem as presented, see if you can change the problem. Ask yourself, what would the architecture look like if I just didn’t have this problem? This can lead ultimately to more elegant and sustainable solutions.

Don’t Be a Problem Solver.

The last two are from Challenge assumptions - especially your own.

Document Facts and Assumptions.

Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a trade-off (performance versus maintainability, cost versus time-to-market, and so on)…

This practice is valuable because by way of listing these factors, it helps highlight assumptions that the architects may have that are affecting important decisions regarding the software that is being designed. Very often these assumptions are based on “historical reasons”, opinion, developer lore, FUDs… In other words, if you’re designing software architecture, write down why specific decisions are made and then think what of these are facts and what are assumptions. Check your assumptions.

Facts and assumptions are the pillars on which your software will be built. Whatever they are, make sure the foundations are solid.

The following list is referenced by Checklists.