Beware the Big Industry Specification Up Front

March 8th, 2010 Comments Off

If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB.  And you were most likely duped into thinking it was great.  I did!  Then I realised it was just a specification.  It was a great big, furry, non-executable PDF.  A specification for managing objects but the creating of these objects were just horrid.  EJB3 was a clean-up exercise, but still far from nice.

A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?

  • Share/Bookmark

What’s worse than BIG DUF? A BIG DIC!

February 4th, 2010 § 6

Most agile people say big designs up front rarely pay off.  You spend so much time doing design that you delay the opportunity of feedback from real, working software.  But I sometimes do BIG DUF.  It’s not that the design is big, it’s the problem that is big.  So I need an up front big picture with just a few big parts.

It helps me conquer and divide.

That’s not a bad thing.  What I find really painful is casting the design in concrete.  When your design is cast, then your mental state is already cast in concrete too.  And that means that it is a lot harder to do the right things.  So, more gets added to the concrete slab and it’s real hard work to break anything off.  When I have a BIG DUF, I often look at how to reduce it, rather than increase it.

I don’t think it’s wrong to have a  BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete).  That concrete block will hurt you later … a lot.

In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (– That’s so lame, I could not resist!)

  • Share/Bookmark

Where Am I?

You are currently browsing entries tagged with Design at f3yourmind.