Taking on dependencies

Taking on dependencies from non-agile teams

Geek Noise — Tue, 08 Jul 2008 19:55:55 GMT

Taking on dependencies from non-agile teams

re: Taking on dependencies

JH — Tue, 08 Jul 2008 22:59:56 GMT

We had the same pessimistic (rightfully so as it proved) view of a dependency we were using on one of my previous projects. The problem came in that the dependency was, essentially, a DAL but they wanted each of our "domain" objects to inherit from the dependency they were building. Nope.. no interfaces here. Have fun!!

It was painful. It was late. It was under-achieving. Ain't it wonderful?

re: Taking on dependencies

Chris Parnin — Tue, 08 Jul 2008 23:42:23 GMT

I find it most successful when the first stage tries establishing a "flow" from start/input to end/display as soon as possible. That way feedback loop brings issues up more quickly.

If there is a dependency, then that means there are already established "clients". This should make things easier in directing development to satisfy others; which is better than development in a vacuum.

@JH

"objects to inherit from the dependency they were building".

Sounds more like then wanted some form of dependency injection: visitor pattern, mixin classes, etc.

re: Taking on dependencies

JH — Wed, 09 Jul 2008 17:40:47 GMT

@Chris

It would sound that way until you have to rebuild your application (from scratch) for a third time because the hammer comes down and they say "You MUST inherit from these objects we will create for you". Then it just sounds like lunacy.

re: Taking on dependencies

Kevin Kerr — Wed, 09 Jul 2008 18:56:33 GMT

I think these recommendations hold true in any engineering discipline.