I know nobody reads this blog anyway, but on the off chance someone does and happens across this article, I’d really like your feedback.
I’ve come to a conclusion lately, well really its more of a theory but one based on my development experience over the past 7 years. My theory is this. Grab the “Low Hanging Fruit” first. I’m not sure if this has already been covered by that Agile stuff or extreme programming, but my instinct is that it feels like it meshes well with that stuff. Hell, maybe I read about the concept it in some book on Agile or XP, and just forgot. But I’m noticing it to be more and more useful.
So what is “Low Hanging Fruit” as it pertains to software development? It’s the easy stuff. It’s instant gratification. It’s the quick and the simple. When you’re working on a software project, chances are you’ll see some stuff that is super easy. On the other extreme, you’ll see other programming tasks that are hairy, complex, time consuming and likely to yield messy code the first time you tackle them. Maybe it’s some really hard integration piece with some archaic mainframe system. Maybe it’s some new API in the .NET framework or a third party component that is hard for you to understand and will take time to get familiar with. It might be some complicated UI element that requires a lot of knowledge about the ASP.NET lifecycle, ViewState or server control development. Whatever the difficulty is, save that part until later. Go ahead—Procrastinate! Do the easy stuff first when possible. Do the stuff that you already know how to do and can get done quickly.
Why do I say this? Well, several reasons. First, as any project gets larger and more complicated, the slower and more difficult it becomes to make additions and changes. You might as well do the easy stuff, because chances are you can really architect these pieces well and make them elegant and clean. You’ll probably learn new things about the project while you’re developing the easy stuff and new things about programming. You might as well take advantage of this new information while you’re not distracted by something huge and complicated.
Another reason is customer visibility. If you are working on the easy stuff, you’ll have a lot more progress to show your customers. You’ll be able to get early feedback and a lot more of it. You’ll be able to react to changes easier than if you spend 3 weeks developing one really complicated backend piece only to find out that many basic assumptions about the application are wrong and that backend piece is no longer being used. Much of what is easy in an application (to me at least) has to do with the UI and simple CRUD behavior: fire up a screen, fill out a form, save the fields to the database, view the saved form and edit it. This makes it look like a lot has been accomplished. If you get the CRUD stuff wrong, chances are your complicated business logic will most likely be wrong too. Save that complicated business logic (or illogic) until you get the basics hammered down.
Finally, there’s the problem with time. We often feel like we never have enough time to finish everything. Chances are you’ll rush pieces at the end. That last minute code written at 3 AM the night before the release will probably not be your best work and might end up on the DailyWTF. Fine. At least the basic framework will be easy to read and easy to change because you wrote that stuff when you were fresh. The complicated code was likely to be ugly no matter when you wrote it, at least the first go around. You don’t want your easy code to look ugly too simply because you were too tired to put the energy it deserved. You can always refactor the complex stuff later but that will be a lot easier if your basic framework is clean and understandable.
Now like any rule in development, this isn’t absolute—it’s a guideline. There’s some situations where you can’t get around having to do all that complicated backend work or integration code done in order to show any data at all. That’s fine—do the simplest part of that piece, then move on to something else that’s even easier. This doesn’t mean leave it half finished for all eternity. Make sure the basic stuff you’ve done works and works well, but be sure to make a note of the complicated development you’ll invariably have to come back to later. When you do come back to doing the complicated code, you’ll find you’re more enlightened to tackle it.
Finally, one note of warning. It has occurred to me that in this article I’m making it sound like you should do all the GUI work first. To some extent, I do like to have an Html/ASPX/WinForm prototype of some sort before I start “really coding.” I show this off and this gives me feedback from my customers. But once you’re in development, work vertically, not horizontally. In other words, if you’re doing 3 layered development, don’t try to finish the entire UI without the business layer, or try to finish the entire data access portion without writing any screens or business objects. Build one module at a time, make it functionally complete and move on to the next one. In the agile world, they would say get one “user story” working at a time. This covers all three layers. If you try to finish an entire layer for every user story for the entire application, you can and will paint yourself into a corner. You’ll find assumptions about your object or data model were just wrong and have to do a lot of rewriting.
Anyway, I hope this is useful to you and I would love to hear comments from anyone who agrees or disagrees with doing the low hanging fruit first.