[jbpm-dev] "Stuff that's hard to change later."

[Mauricio Salatino]

Good article man. We need to be focused on that.. and as the definition
mention.. Architecture is hard to change later.. I totally agree with that!

On Tue, Oct 25, 2011 at 8:40 AM, Marco Rietveld <mrietvel at redhat.com> wrote:

>
> Hi guys,
>
> It's a little wordy -- and to some extent just a logical extension of "The
> Mythical Man-Month<http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959>"[1]
> (which I also strongly recommend), but there's a decent article about
> design/architecture here:
>
> http://www.ibm.com/developerworks/java/library/j-eaed1/index.html
>
> In particular, the following:
>
> Which leaves my favorite definition for architecture:
>
> "Stuff that's hard to change later."
>
>  ...
>
> The third enabler of accidental complexity is *irreversibility*. Any
> decision you make that cannot be reversed will eventually lead to some level
> of accidental complexity. Irreversibility affects both architecture and
> design, although its effects are both more common and more damaging at the
> architectural level. Try to avoid decisions impossible or cumbersome to
> reverse. One of the mantras I've heard some of my colleagues use is to wait
> until the *last responsible moment*. This doesn't mean that you should put
> off decisions too long, but just long enough. What is the last responsible
> moment you can make a decision about some architectural concern? The longer
> you can avoid the decision, the more possibilities you leave open for
> yourself. Ask yourself: "Do I need to make that decision now?" and "What can
> I do to allow me to defer that decision?" You'll be surprised at the things
> you can defer until later if you just apply some ingenuity to your
> decision-making process.
>
> and lastly:
>
>  The last of the overarching concerns for architecture and design is a
> phrase I've made up called *rampant genericness*. We seem to have a
> disease in the Java world: overengineering solutions by trying to make them
> as generic as possible. The motivation for this is clear: If we build in
> lots of layers for extension, we can more easily build more onto it later.
> However, this is a dangerous trap. Because genericness adds entropy, you
> damage your ability to evolve the design in interesting ways early in the
> project. Adding too much flexibility makes every change to the code base
> more complex.
>
> Of course, you can't ignore extensibility. The agile movement has a great
> phrase that sums up the decision process for implementing features: YAGNI
> (You Ain't Gonna Need It). This is the mantra to try to avoid
> overengineering simple features. Just implement exactly what you need now,
> and if you need more stuff later, you can add it then. I've seen some Java
> projects so bloated with compromises in both architecture and design made at
> the altar of genericness and extensibility that the projects failed. This is
> of course ironic because planning for the project to live as long as
> possible truncated its life. Learning how to navigate the fine line between
> extensibility and overengineering is tough, and it's a subject I'll come
> back to frequently.
>
>
> Thanks,
> Marco
>
> --
> jBPM/Drools developer
> Utrecht, the Netherlands
>
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>


-- 
 - CTO @ http://www.plugtree.com
 - MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20111025/18fefc60/attachment.html