How mock objects make Gantt charts (more) useless

http://jakegoulding.posterous.com/how-mock-objects-make-gantt-charts-more-usele

by shepmaster • 15 years ago

15 10 15 years ago

jakegoulding.posterous.com

Groxx3• 15 years ago

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.

shepmaster3• 15 years ago

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. :-)

Groxx3• 15 years ago

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

rheide2• 15 years ago

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.

shepmaster3• 15 years ago

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.

rheide2• 15 years ago

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.

tjpick• 15 years ago

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

Scary.

How mock objects make Gantt charts (more) useless

Related Stories