One of the most valuable lessons I ever learned during my time at university, was the methodology of Divide-And-Conquer.  This can be applied to anything, but in Computer Science is vital for dissecting those complex problems into their component parts.

The only problem was that, like a lot of things I did at uni, it wasn't really put into practice once the coursework and exams were over.  When you start work it's all about delivery - you don't have time to really think things through in this way, especially when you only have a couple of days until what you're working on is in the product, finished and looking shiny.

Or at least, you don't think you have the time.  But turns out the lecturers and academics are right after all.  Taking the time up-front to fully understand a component, whether it be for internal use or a UI control, saves a lot of hassle in the long-run.  Think incomplete specifications, unexpected surprises, and debugging particular scenarios during a defect cycle.

I've been thinking about this recently as I have to get to grips with a new control, and slot it into an existing application.  Whenever I start to work with a control that I'm unfamiliar with, I like to build myself a little sandbox and give it a good going over, making sure that I know what's going on in an isolated environment, without having to worry about the rest of the codebase affecting it.   I might not get as much time on it as I'd like, but there's always that balance. 

What this lets me do is get to grips with what I'll be using the control for, how it binds to data, how it can be controlled via it's interface rather than using the 'Smart' Tags to configure it.   

I've been putting this technique through it's paces for a couple of years now, and it's clear when I look back at some older code how much of a difference it makes.  The solutions might take a little longer to develop, but the result is a cleaner implementation, for the reasons outlined above.

If I was President, I'd like to see a lot more of this sort of thing.  Whenever a new component was being developed, it should have an associated driver (prototype/sandbox - call it what you will) which configures and simulates the component in a real-world environment, but completely isolated of other parts. 

Of course, what this ultimately results in is a suite of Unit Tests for your newly developed component.  So this is hardly a revolutionary idea, but supports that we are on the right track.