Eivind
Is this you? Claim Profile »
3 months ago
in [link] Package by feature on Thinking inside a bigger box
I find it quite natural to organize user interfaces, "service layer" functionality and support packages by feature, but I am not so convinced concerning cross-cutting domain classes. A good architecture should also support your needs for variation. If for instance you need both a rich GUI, a web interface, an XML interface and test routines on top of your domain, would you melt it all into one single package then? Maybe a pragmatic mixture with an open mind might be an option?
5 months ago
in Teaching good software design on Thinking inside a bigger box
There are a lot of deseases out there, for example architecturitis, analysis paralysis and big design up-front, just to mention a three. And why not add object-orientation itself to the list? It is much like eating and drinking, it may give you a lot of pleasure, but abused, it often results in a lot of pain. But that doesn't mean that we should stop doing it, does it?
I think a keyword you mention here is "needlessly". I use to teach that if you don't possess the modelling and abstraction capacity required for doing good object-orientation, you'd better stick to the plain, old, structured way of thinkink. At least, that gives you something that is working in the short term, although perhaps not as modifyable in the future. Object-orientation and architectures are good for managing changes. At the same time, changeability implies complexity, so they ought to be kept at a minimum. In fact, we may make everything changeable, at the price of making is so complex that it is not changeable any more. That, may be, is a good definition of architecturitis.
I think a keyword you mention here is "needlessly". I use to teach that if you don't possess the modelling and abstraction capacity required for doing good object-orientation, you'd better stick to the plain, old, structured way of thinkink. At least, that gives you something that is working in the short term, although perhaps not as modifyable in the future. Object-orientation and architectures are good for managing changes. At the same time, changeability implies complexity, so they ought to be kept at a minimum. In fact, we may make everything changeable, at the price of making is so complex that it is not changeable any more. That, may be, is a good definition of architecturitis.
5 months ago
in Learning is a social endeavor on Thinking inside a bigger box
I'm just about to redo that example. Thanks for the tip. I'll keep that in mind.
5 months ago
in The Myth of the Silo on Thinking inside a bigger box
Audacious assertions!
Fact 1: "Each layer was added in an attempt to make it easier for someone to integrate with the system. Each layer makes the whole harder to understand." Would you call this a silo? Each layer is probably added for, and probably serves, its purpose of adaption or adding value. Different layers may exist in parallell or on top of each other. New and different integration needs may solved on top of previous, lower layers. That seems natural. Unless you only conceive the top as being "the service".
Fact 2: Important learning. Silos may be only apparent and present integration interfaces. Thanks.
Fact 3: Yes, few examples of successful, euphoric, large-grained integration and reuse exist, and probably for good reasons. But isn't there an agile, medium-grained middle way between that and silo thinking?
Ode to silos that in fact aren't and to agile, timely integration?
Fact 1: "Each layer was added in an attempt to make it easier for someone to integrate with the system. Each layer makes the whole harder to understand." Would you call this a silo? Each layer is probably added for, and probably serves, its purpose of adaption or adding value. Different layers may exist in parallell or on top of each other. New and different integration needs may solved on top of previous, lower layers. That seems natural. Unless you only conceive the top as being "the service".
Fact 2: Important learning. Silos may be only apparent and present integration interfaces. Thanks.
Fact 3: Yes, few examples of successful, euphoric, large-grained integration and reuse exist, and probably for good reasons. But isn't there an agile, medium-grained middle way between that and silo thinking?
Ode to silos that in fact aren't and to agile, timely integration?