4 Rules

[Himanshu Ahuja]

Hello Corey

Congrats on new book!!!

Why adhering to good design principles so hard? How can we formalize good desings process in to software development lifecycle?

Thanks.

[Junilu Lacar]

Question for you: why do you think there's a need to "formalize" good design process in the software development lifecycle?

To me, that's kind of like asking "How do I formalize brushing my teeth in my bedtime routine?"  Really? Is there really a need to "formalize" doing something that's good for you?

[Junilu Lacar]

I think a better question might be: "How do I make a habit of adhering to good design principles?" which isn't unlike asking "How do I make a habit of brushing my teeth before I go to bed?"

[Junilu Lacar]

The answer to both those questions, BTW, is simple: Discipline.

[Himanshu Ahuja]

I think due to lack of better words you did not understood my question, what i meant to say was we know following good design principles is good but we hardly see the discipline to apply these in real world and good application is very subjective and depends on eexperience level of developers, that is why question around ideas for formalizing application of design processes via tooling or rulebook or other means.

[Junilu Lacar]

Himanshu Ahuja wrote:... we hardly see the discipline to apply these in real world and good application is very subjective and depends on eexperience level of developers, that is why question around ideas for formalizing application of design processes via tooling or rulebook or other means.

I still don't know if "formalize" is the right word to use in this context. The definition of "formalize" is "to make official or legitimate by the observance of proper procedure."

Are you thinking about automation? Or maybe you are thinking in terms of the opposite of "subjective," which is "objective." So maybe you're thinking of how to apply design principles in code more consistently and objectively? Is that it?

[Himanshu Ahuja]

Yes and if there are any tools available to do so

[Liutauras Vilda]

Himanshu Ahuja wrote:...we know following good design principles is good but we hardly see the discipline to apply these in real world...

Robert C. Martin (Uncle Bob) in one of his conferences described that as "Professionalism", in this case just would be an opposite. And to grow that mentality I think you need to start to work on that early. We often see on these forums students coming along with their assignments to figure out one or another thing, and when everybody points out about some other things to improve, the usual answer(s) is, "will have in mind in the future", "will do next time", "It is fine, it is my first year in a class...".

So these habits rot to what you just described. Lack of responsibility, or maybe even irresponsibility of individual developers.

[Burk Hufnagel]

Himanshu Ahuja wrote:Yes and if there are any tools available to do so

There are plenty of tools out there, like SpotBugs (successor to FindBugs) and SonarQube (with plugins), and most IDE's will support setting up coding standards and showing you when your code doesn't follow them.

[corey haines]

I think an important question to ask is

"What is a good design principle?"
or perhaps
"What is a good design?"

Before we can ask about why we can't formalize them or why don't we see them happening more often. This can be an interesting discussion, but it is often context-specific and hard to get to "good design." Depending on the situation and the person, I think you'll often get differing opinions.

I like the idea of "better design" that takes into account relative benefits of different designs based on the context.

As an example, if it easier to rewrite something than to maintain it, then the definition of "quality" is suddenly changed.

Even something as simple as "no duplication" can have varying levels of adherence and return on investment. Even the definition of "duplication" can be argued .

I know this is sort of a non-answer, but I know that, in my past, I've fallen into conversations about "good design" that bordered on harmful for certain situations.

[corey haines]

All that being said, I do think that "better design" comes from two things:

- Understand your context, especially around the need for future change
- Apply the 4 rules of simple design (specifically naming and duplication elimination) within the context that need for change.