Don't Stay Stuck

If you write code professionally, you will have days where you find yourself utterly stuck on a problem. In fact, some days coding feels like trying to wade through quicksand: The harder you struggle to get out the more stuck you find yourself. Getting into one of those situations where you are stuck and can't find a way out is perfectly normal. And it is perfectly acceptable for a professional programmer as well. Every programmer finds themselves in those situations from time to time. Getting stuck is a natural part of creative work like programming, and as such we must simply accept that we get utterly stuck now and then. The important part is what you do about it. As with quicksand the trick is to relax a bit, sit back, and realize that you need to seek help. Not all programmers realize this, but the best ones do.

When faced with an insurmountable problem some programmers just press on and try to work through it. That usually means they start thrashing; they run around in circles without getting anywhere. While this might keep them warm, and even make them seem really busy and hard working it doesn't help the project. Some programmers sort of lose interest and start surfing the web or drinking inordinate amounts of coffee. That doesn't help the project either. To get out the situation you're stuck in, you probably need help - I know, I always do. So seek help.

Seeking help can mean a number of things depending on the problem you're facing. If the problem is on the code level try asking a teammate to come and pair with you - or if you're already pairing, ask to switch pairing partner - that extra set of eyes usually helps. If the problem is a design issue, again ask a teammate to help you out, but get up from the keyboard and go to the white board. Again the extra set of eyes - or even just the process of explaining the problem - usually helps. If the problem isn't technical but has to do with say access to the right tools, the right level of support from third parties, or unrealistic deadlines, ask your project manager for help. And if he or she is not able or willing to help, don't be afraid to escalate the problem to his or her boss - it's the professional thing to do. As I said: Seeking help can mean a number of different things.

But whatever you do, don't just stay stuck. Do something about it.

Immediately Functional? -Really?

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.

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?