Following up on my last post I want to focus one point in the second decision diagram in that post. The diagram is a rule of thumb for deciding what you want a framework to implement for you, and it looks like this:
I want to focus on the "immediately functional" box. It says that you only want to use features in a framework that work in your context as they are. What does that mean? What if the feature needs to be configured just right to work in your context? Or needs to be extended through some extension point? Or needs to be modified slightly by cracking open the framework code? Or will work in the next release according to the frameworks roadmap? Lets look a these in turn.
Is configuration OK? Yes. Of course it is...But only to a certain point beyond which you drown, then you're usually better off building the whole feature by yourself. And keep in mind that frameworks that dont ask you to do a lot of configuration, while still implementing enough are (or course) preferable. Conventions are good at that.
Is extending through extension points OK? Yes. Of course it is. Iff its done through supported extension points. If you extend through something that isn't meant to be an extension point, you will probably have a hard time maintaining that extension, and would usually be better off building the whole feature specifically for your purpose.
Is tweaking the framework code itself OK? No, and not even if you're in a position to merge your changes back into the framework. Because even if in that case, you're now the maintainer of part of the framework, which is not what you set out to be, when you chose to use a framework. In this case you're better off building your own and maintaining that at your own pace, and according to your own needs.
Is waiting for a feature in the next release OK? It depends...as they say :-). It depends on when you absolutely need the feature, and on when you need to start developing on the feature. In other words it depends on whether you have reached the last responsible moment or not. The last responsible moment is the moment at which you have to make a decision.It not just any moment at which you can make a decision. That's likely too early. It's not simply the last minute, because at that point you dont necessarily have a choice anymore. It's the when you reach the point where you need to start developing the feature but still have time to think your choices through and make a decision. If you dont really need the feature yet, postpone to a later iteration, and decide on whether to use the framework for that feature or not, at that time. Maybe you can postpone long a enough for that new release of the framework to come out. At that point deciding whether to use the implementation in the framework or to build your own is probably easy. If you can't wait that long before starting developing the feature, you might still be able to postpone the framework vs DYI decision: Create a clear interface to what you expect the framework to implement in the next release, and then - when you have to - either use the framework to implement the interface or roll your own implementation. You might even hedge the your bets by defining the interface and simultaneously develop against the interface and rolling your own implementation of the interface. If the framework should be released with a suitable feature while your still working on your own implementation, you have the option to switch without throwing too much away, on the other hand if the framework doesn't release anything suitable you're well underway too.
It's about making the decision at right moment - which is at the last responsible moment because that is when you have the most, and best, information to base the decision on, while still maintaining the freedom to actually decide for yourself.
Friday, August 20, 2010
Wednesday, August 11, 2010
What Should a Framework Implement?
In my last post I wrote how you want a framework to give you a way out, when parts of the framework turns out to be too constraining. In this post I want to talk a bit about what you actually want a framework to cover in the first place. But first a little detour.
Build or Buy?
When an organisation needs a new software system, should it build the system (possibly using contractors/consultants) og buy the system (as in find a suitable COTS solution)? That's one of those questions being asked all the time, and it's one those questions that - in general - can only be answered with "it depends...". It's also a question I'm faced with from time to time in my work, and the first answer is always "it depends..".
I watched this talk by Neal Ford on emergent design recently and about 3/4 through the talk he adresses the build og buy question using this diagram:
The diagram says the new system should only be bought if it is not strategic (i.e. not part of what differentiates the organization), if there is a fully functional candidate COTS solution readily available, and that candidate is extensible (i.e. provides ways out, when the solution is too constraining). Especially the first clause I find interesting. Everything that is strategic, and thus everything that is part of what differentiates the organization should be purpose build in order get all the details exactly right, so as to support and further the differentiation.
So in a build situation, then what? Well, often one of the early things done is to choose a framework to build on.
What Should a Framework Implement?
In choosing a framework the first thing to consider IMO is what you actually want the framework to cover. If you've already decided not to buy a COTS solution, then there must be some part of the system you think should be purpose build. On the other hand you dont want to build everything from scratch (e.g. if you're building a web app for renting cars you dont want to start by building a web server). You want to concentrate your efforts on the really value adding parts of the system. Those parts are the bits that set this system aside from all others (in the car rental example that would be the parts for selecting cars, handling special offers, making reservation and so on). These are the differentiating parts. So you want a framework that implements all (or most of) the things that are not differentiating the system. But only if it is fully funcitonal and readily available, and only if it provides ways out.
So I end up with this diagram for deciding whether a given part of the system should be implmented by a framework or purpose build:
Looks familiar?
Build or Buy?
When an organisation needs a new software system, should it build the system (possibly using contractors/consultants) og buy the system (as in find a suitable COTS solution)? That's one of those questions being asked all the time, and it's one those questions that - in general - can only be answered with "it depends...". It's also a question I'm faced with from time to time in my work, and the first answer is always "it depends..".
I watched this talk by Neal Ford on emergent design recently and about 3/4 through the talk he adresses the build og buy question using this diagram:
The diagram says the new system should only be bought if it is not strategic (i.e. not part of what differentiates the organization), if there is a fully functional candidate COTS solution readily available, and that candidate is extensible (i.e. provides ways out, when the solution is too constraining). Especially the first clause I find interesting. Everything that is strategic, and thus everything that is part of what differentiates the organization should be purpose build in order get all the details exactly right, so as to support and further the differentiation.
So in a build situation, then what? Well, often one of the early things done is to choose a framework to build on.
What Should a Framework Implement?
In choosing a framework the first thing to consider IMO is what you actually want the framework to cover. If you've already decided not to buy a COTS solution, then there must be some part of the system you think should be purpose build. On the other hand you dont want to build everything from scratch (e.g. if you're building a web app for renting cars you dont want to start by building a web server). You want to concentrate your efforts on the really value adding parts of the system. Those parts are the bits that set this system aside from all others (in the car rental example that would be the parts for selecting cars, handling special offers, making reservation and so on). These are the differentiating parts. So you want a framework that implements all (or most of) the things that are not differentiating the system. But only if it is fully funcitonal and readily available, and only if it provides ways out.
So I end up with this diagram for deciding whether a given part of the system should be implmented by a framework or purpose build:
Looks familiar?
Labels:
Opinion,
software design
Subscribe to:
Posts (Atom)