Why is good design important?

Well designed Code Vs. Code That Just Works!

 One of the biggest lessons I've learned in my Android development experience to date
 is the battle between writing code that works, and writing code that is well designed. 

"What do you mean 'well designed'? I thought the purpose of writing code was to solve a problem, you know..get something to WORK"??

This logic couldn't be more flawed. It goes back to what our moms used to tell us when we were kids(at least mine did), "do it right the first time, and you'll never have to do it again". In a sense, this can be applied to software development. Whether you're a beginner, intermediate or seasoned vet..this understanding is vital to your success or failure in developing mobile applications, or any software for that matter.

Writing code that just works. It's not beautiful, but it gets the job done.

There's good and bad in everything, right? This approach is no different, and in some instances the q&d(quick and dirty) approach is just fine.

For example, when trying to find a quick workaround to a persistent problem in your code that you just can't crack. You're trying to figure out how to download some images off a server and display them in  GridView or Gallery that you've got set up in your Android project. It's a solo project anyways, no other programmers will ever see it, it will never be published, and you're just testing something anyways. Quick and dirty is fine here, because the purpose here IS to "just get it to work". So you hack away at some stuff, forgetting about Threads, Handlers, Background Tasks, Lazy Loading etc. You go ahead and write up some stuff that grabs your images off the server and displays 'em, all on the UI thread(more info on this later, it refers to the main thread in you Activity). Design patterns, maintainability and extensibility don't matter because you are just placing things in line to get them working anyways. You can refine later. Gotcha.

Now, when will this approach fail..and subsequently cause more harm than benefit? You ready for the truth? In EVERY other case.

Writing code with the future in mind. Maintainable, Extensible. Elegant.

I haven't been developing on Android for long, and before that I had never written any professional, published work. The first object oriented programming language I had experience with was C++ freshman year of highschool. I was on the robotics team and we wrote code in C++ that would communicate with a robot's cpu and get it to do different things. Before that, I had only messed around with Html and Javascript when I was around 12 or 13. So as you can see, Java(and Android) have been what I've spent most of my programming time with thus far.


 Believe me when I say that the lessons I learned during this process have been vital, and I'm glad I made some of the mistakes I did early because I learned to see things from both sides..and still learning!

One of the bad habits that I picked up early on, and admittedly still do this sometimes today; is what I like to call "raw programming". I don't know if that term or expression even exists in the computer software world, but I think it fits perfectly. It should. 

What I mean by "raw programming" is just what I mentioned above. Hacking away at some code, without any real direction or consideration for where this ship is going. The reality is that the ship is sinking, fast. You know the problem you're trying to solve, you have a vague idea of how to fix it. Add that with some half-assed inspiration and you're in for a bad time. You rush the work, racing to escape from the dreaded ANR dialog(Activity Not responding, aka "Force Close"). You write the code, screw the comments(No one else is gonna see this anyways, right?). You eventually get rid of the bug and all is well with the world.

You continue working, and after a few hours and a couple replays of your favorite Bob Marley album, you discover another bug. This time you haven't a clue of what happened, but you know that it's related to code you chopped up earlier(at least you think it is).

I like to call this phenomena "quick & dirty dominoes". Dominoes because what happens is that due to your initial half-assed, indecipherable "solution" in the beginning..subsequent bugs were created and as time went on they kinda just snowballed into a big clusterfuck of suck. Sort of like the domino effect, get it? Now you're stuck with no way to go forward. Where did you go wrong?

You wrote horrible code. That's where.

Make it Maintainable and Extensible.

 

Writing maintainable, extensible code can be difficult to grasp. Mostly due to the words "maintainable" and "extensible". Don't worry about these, they are just words. Just try to remember these two points when developing your apps, and if you can at all times(even in solo development), your Android app development career will be that much easier and less time consuming.

1 ) It is ALWAYS time for spring cleaning.

What I mean by this phrase is that always bear in mind that you will have to continuously clean, improve and maintain your app. Nothing is worse than having to go back and figure out what certain constructs do or what the purpose of this chunk of code is for. Design for maintainability. From the first moment you start building your app, keep this in mind. Don't add unnecessary dependencies. Don't work hard, work smart. Find the shortest but most efficient way to a solution. And if you must choose between "quick and dirty" or "long and elegant", always choose the latter. Keep related things together, and unrelated things separate. Remember that 20% of software development is making, 80% is maintaining.

2)  Think ahead. Design for the future.

Always keep the future in mind. Get into the habit of designing software that can easily adapt to future changes(if you so choose to include them), and improvements.This goes back to what we said earlier about not having too many dependencies and avoid q&d as much as possible. Imagine that if you were to remove a core feature or API from your app, would that break other parts of the program? Could it be fixed easily ?