software model driven approaches
Say that lazy means not going till something’s end. Lazy modeling means doing models that don’t hold all the material they could carry. Say we talk about MDD(a) (What else? ;D), so we talk about a PIM(b) which describes business/functional/architectural requirements.
This PIM holds decisions about a solution to an initial business need that has be solved with (part of) an application:
For sure, such information is highly valuable as directives to the material solution builders – I mean developers. Usually developers are human, but in MDD part of their job may be delegated to code generators (or something equivalent like a model interpreter).
Wait a minute. How do developers work when they don’t have a PIM in input? Here I talk about 90% (at least) of application development projects, even if we are mainly interested with the others 10%. They indeed have the same kind of input, roughly:
However these specifications are given in a usually less formal, more opened, more inconsistent, but maybe easy for anyone to read, so in a more lazy way.
This is a first laziness footprint: we are all used to deal with laziness as the way we build applications is based on lazy fully adopted practices.
The main impact? Final decision is delegated to developers. And unless eventually using high level TDD(d), final implementation is always the result from a negotiation between stakeholders and developers… And all the Agile project team around them ;D !
For some other reasons, among them the impossibility to fully model the real world (ask physicians, or better: meteorologists!), we can’t have complete models of fully expressed needs:
Don’t try to put all the stuff in models. Except if you want to work without any human developer, try to put sure things in models and let a part of the work to developers. They are used to it… And they do love that!
Be lazy: keep models simple. It’s always better than no model at all. And if developers can easily understand models and their requirements embedded semantic in regard with what they have to code… They even should forgive you to use some code generation ;D
(a) MDD = Model Driven Development, which stands here for any forward-MDE approach including MDA
(b) PIM = Platform Independent Model, which stands for any DSL, based on UML or not
(c) here business objects stand for business classes…
(d) TDD : Test Driven Development
Featured image taken from http://users.abo.fi/mcollan/lazyusertheory.html