Oh yes, we all build software by the way of construction. In a typical home construction project, the process goes like this -> Landscaping -> Foundation -> Building blocks -> House itself -> Interior -> Painting -> etc. In software development terms, it simply mean developing from the back to front: Architecture -> Backend - > Databases -> Business logic -> Other logic and services and then UI.

I've been developing that way for years and I have no idea why, I guess I just join the crowd but I've been thinking, how does that affect the functionality, speed, productivity, etc of my application. Is it really necessary to start from back to front or I'm I just doing it that way because its the conventional and most common route of most software developers? and how does it really fit in with large development teams versus individual developers/consultants like me?

Numerous projects have gone by incomplete because I got tired, gave up or moved on to something new and I tend to seat back once in a while and think, why do I have so many incomplete projects and excellent ideas? Needless to mention that most of these ideas are already built by some dedicated group or organization.

So, I sat down and decided to drill through my life and how I usually go about executing new ideas - trying to figure out where I normally go wrong. I did find a whole lot but with great surprise one of the most common was that I had lots of completed databases and business logics than UI. So I came to a conclusion that one of the reason why I quit in the middle of a project is because I do not have enough or sufficient will power to push past the middle layer to the presentation layer and being the "great designer" that I am - I do get bored when it comes to UI.

There it is, I suck at UI or should I say Lazy! Therefore, I've decided to get the lazy part over with first and then move on to what I do best, coding. OK, I'm not saying reversing the process is always best but just think about it, if you have a dedicated team with developers, designers, architects and DBA's, it doesn't matter where you start the chances of you succeeding by using the conventional way is higher than that of a consultant, at least from my perspective.

If you are a single developer, trying to build a huge project, the last thing that you need is distraction. As a matter of fact developing the conventional way can be risky at times, how many times have you built backend, business and etc...and your customer(s) keep asking "when are we going to see something?" and your response is - very soon, we are working on the guts, the main engine! Months later, getting ready for your first demo and ta-da - customer(s) response = "That's not what we were expecting".

Most or if not 90% of the time, the people that you build for have no idea of the backend and could care less, their interest is the UI and functionality. How does it look? can I do this? How easy is it to use? what if this I click this? You are rarely asked about code and how you built it or even database schemes.

Therefore, reversing the software development process will be very helpful to developers like me. Designing the UI, should be the first step. Get it over with and move on, have the end users test and agree to the looks and then build from there. This process has also made my project plans a lot smaller and easier, using the conventional style, I always end up with a whole lot of scope creep, adding more stuff - oh this will be cool! but with the UI in place, I know exactly what I want and the possibility of adding more features is pretty slim, although possible but you really have to go out of your way.

Reversing the process is pretty easy and straight forward: Start by designing the UI or have a designer do it for you but make sure you have a pretty clear idea of what you want, menus and features and have the UI be designed with that in mind. The rest is 'piece of cake', you could jump straight into business and other logic and then data but I normally jump to data and then logic. I model the database for the UI and then build the logic to tie them together. TA DA!!!