How mock objects make Gantt charts (more) useless | Hacker News Reader

How mock objects make Gantt charts (more) useless

jakegoulding.posterous.com

15 pointsshepmaster10 comments

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.

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

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

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.

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.

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.

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

Scary.

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.

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.

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.

Reply on news.ycombinator.com