

How mock objects make Gantt charts (more) useless - shepmaster
http://jakegoulding.posterous.com/how-mock-objects-make-gantt-charts-more-usele

======
Groxx
No, Gantt chart elements can have multiple predecessors. Here's one that
actually allows you to do so: <https://app.gantter.com/> and here's Wikipedia
with a multi-predecessor example (E):
<http://en.wikipedia.org/wiki/Gantt_chart#Example>

Not that many support doing so, nor do most suport the full range of what
they're supposed to be able to do. That's a different issue. Personally, I
think the single greatest flaw with Gantt charts is that they're (technically)
supposed to always have everything add up to 100%. Which means either you set
something up to do it for you, or you have _incredible_ book-keeping that
becomes ridiculous when you have changes or more than a handful of entries.

~~~
shepmaster
Great point, but does having multiple predecessors negate the argument? Each
predecessor is simply another set of mock objects to create. The idea is that
Gantt charts show an explicit dependency graph, but mock objects allow you to
break that graph in order to continue to develop when otherwise you might not
have.

Thanks for the link to the app, but I hope I don't have to create any Gantt
charts myself. :-)

~~~
Groxx
Essentially, yes, I do think it does. The second example lacks a measure of
time to _complete_ those units, so they would end up coming to the right - the
mock objects are just mocks, the real ones have to be made still. The "heavy-
handed dependencies" still exist, because it won't compile without the mocks,
and won't run without everything being built.

In a Gantt chart, you'd also probably have all those under the same higher-
level WBS number[1], so they're conceptually grouped. Reflecting how they are
all related, and are developed at the same time. Or maybe you'd group the
entire project until completion under a single one. Or something.

In any case, you'd have something like:

    
    
      {               1: project scope                         }
      { 1.1: stub it out  }  {1.2: finish it }  {1.3: deploy it}
      [build] \
      [mock]  - [integrate] - [build] - [test] - [deploy]
      [mock]  /             \ [build] /
    

which is fully within Gantt capabilities.

Not that I'm really a fan of Gantt charts. But most of that has to do with how
the UIs have been implemented, which tend to prevent at-a-glance information,
because the details are decoupled from the chart. Useful for managers, not so
useful for the ones _making_ those parts. They're also usually just a
spreadsheet with a static chart nearby, which prevents a lot of simple
twiddling of details that are difficult in spreadsheet form.

But the only difference I see so far is that the mock-objects have a shade on
the left which shows they're mock. Which is something that is possible to do
within a Gantt chart, if not something that's implemented frequently enough to
make it practical.

[1]: <http://en.wikipedia.org/wiki/Work_breakdown_structure>

~~~
shepmaster
Ah, I think I understand your point now... correct me if Im wrong, but I think
you are mostly pointing out how my headline is sensationalist. I'd probably
agree with that, and blame it on my inexperience with "hardcore" Gantt charts.
:-)

My real point is that project plans often devolve into "we must do A before B
before C", which artificially serializes development. This sequential nature
has often been presented in Gantt chart form, so perhaps my ire has been
poorly aimed.

~~~
Groxx
Gantts do tend to support over-serialization (I think it's the lines. Mustn't
mess up the pretty lines, must we, Precious?), but that's an organizational
abuse more than anything.

A little sensationalist, yes, but I'm really not seeing any conceptual
difference that's not part of the basic behavior of Gantt charts. If I'm
missing something (fully possible, I'm a bit distracted), I'd be interested in
knowing what it is.

~~~
wisty
Gantt charts were designed for "real" engineers, who worry about things like
pouring in the cement foundations before painting the doors.

They are just not designed for agile programmers. They can be used for
software, and are somewhat useful, if only because nobody ever reads the spec,
but they can see what must be done on the Gantt chart.

------
tjpick
A mixture of concepts from project management, software architecture, and
testing artifacts.

Scary.

------
rheide
He's conveniently forgetting the time it takes to define interfaces+contracts
and to make mock objects that do decent job of mocking their real counterpart.

~~~
shepmaster
I certainly didn't mean to suggest that creating mock objects is free. In the
second graph, I added an extra week to develop the application logic and the
UI. Originally these were scheduled to take 2 weeks, so 1 week is a pretty big
chunk of time in comparison!

I also call out this fact later, when I list some potential downsides to
developing this way: "The cumulative time for the sequential method is seven
developer-weeks, but the parallel method takes ten developer-weeks."

The time to define interfaces and/or contracts should be a wash. If you design
up front, then you can just use that, and if you are working in a more agile
manner, your teams can communicate and experiment with getting the right
interface. Either way, you have to spend time.

~~~
rheide
Good point! One of the things I always end up spending more time on is
defining the interface, so I thought I'd point that out. I think spending a
week on a decent interface is a fair amount, but (like you also mentioned just
now) that doesn't mean that all of the interface design has to take place up-
front.

