+972 52-548-6969
Zones of Quality
In most of my applications, I tend to work according to a method that I call zones of quality.
Case in point, I am currently writing an application that does [doesn't really matter]. This application needs data entry screens to get data in, but while data entry is a big and complex topic, it is not something that is even remotely related to the real business value in the system.
For that matter, a lot of the domain logic of the system is secondary and only there as a supporting role. So I give them both the exact same treatment: Quick & dirty implementation that will move them out of the way and allow me to focus on the real business value.
Once I get that out of the way, we know that the system can work as needed, all we need to do now is replace the quick & dirty implementation with a production ready one. This is often a tedious process, but a very straightforward one.
It doesn't make sense to spend time & effort on external concerns of a system until you have gotten the main one down pat.
Comments
Is this kinda like the Onion Architecture? :)
No, because the focus is different.
The most important part of my current application is reports, for example.
Domain model looks like hell, and the logic is disgusting. But the reports model is very well crafted.
@Ayende: I was joking, man. :)
Good post, though.
Ayende, I think it might work as you say, but not in every situation. For most 'businesses' i know the only thing that has value is what they see, I mean the user interface. And no matter what is the system architecture, end users don't see any value in its internals, don't understand it and concentrate only on what's visible for them. If I were leading the project in this 'Onion' methodology, almost every customer would have thrown it away after seeing frist GUI prototype, or at least they would be very disappointed.
This remark applies also to some managers.
Ommm... I'm not sure... the problem is in many shops it is really hard to justify going back to a working "quick & dirty" code, and replace it with "production ready" code.
Sometimes the developers won't do it, if they want to do it, the PM won't let them, and if they want, the "business guys" won't like it and they will demand more new features.
Bottom line: I think it works in special scenarios that you have the necessary discipline AND authority to do this
I'm with RG... my customer / boss has a fixation with good design (which I don't do anyway, someone else is responsible for that). Nothing matters in the application until he likes the design. It's annoying.
Comment preview