Bringing order to chaos
— NOTE: This was an unpublished draft from a couple years ago. I'm not even sure why I wrote this, but after reading it, I figured it wouldn't hurt to just publish it, even if it feels rough and unfinished. There are some good pieces of information and knowledge in this blog post, and it would just feel wrong to keep it to myself. I might come back to it in the future and re-write it (maybe).
After dividing your big problem into several small ones, the next big question is: “where should I start?” It’s easy to get confused when you’ve got lots of little problems of similar difficulty, and it’s particularly frustrating when you start with something you shouldn’t have, and you only end up losing time. We’ll think of it like a puzzle. One often starts a puzzle by identifying the part that will make it easier to identify and put together the rest of the pieces, something I like to call a base. For example, if the puzzle is a landscape with lots of flowers and a house in the distance, I’d look for the house pieces, since they’ll serve as a guideline later down the road.
By now, you should already know that use diagrams, use cases, and any other visual aid that comes to your mind is a great asset when it comes to software development, so it should come as no surprise for me to tell you that these visual aids will be the ones that will help you figure out where to start.
We will need what we call an “architecture”. We’re referring to a design structure that will help you identify the most important parts of your program and comprehend the relation between these important parts. An architecture will guide us when we try to convert the big mess we’ve got into a full-fledged application that meets the consumer’s needs. This will all be possible if we stick to what we already know: our program needs to do what the customer wants it to do, we need to add flexibility to our code, and strive for a maintainable and easily reusable design.
In order to identify what’s most important for your application, you’ve gotta ask yourself three very important questions:
Is it part of the essence of the system?
What we mean by “essence” is if it really represents a crucial part of what the system can do. That is, if a certain part is of utmost importance for the program to work as intended, then it means it’s part of the essence. If you can easily imagine your system working without that particular part, then it means it represents more of a supportive role rather than a crucial one. In summary, one could say that the essence of a system is the most basic representation of the system (what it is and what it can do).
What the hell does it mean?
It’s easy to identify crucial parts of the system, because you most likely won’t be able to decipher what the hell that part is supposed to do exactly, you just know that you need it. If you find yourself in the situation where you can’t quite put your finger on what a certain something really means, you’ll probably want to spend time on that particular something earlier rather than later, because it could bring trouble down the road.
How the hell do I do it?
Another easy way to identify a good place to start, is when you find something that looks really damned hard to implement. If that’s the case, you’ll probably want to spend some time on it early for the same reason as before: it could mean trouble if you leave it for later.
All this means is that in order to identify a truly significant piece of your system, you’ve got to identify all those little things that will introduce risk to your project. The riskier the better, because once you get rid of a significant part of the risks, it can only mean that there are less risks down the road, making it easier to build on top of what you’ve already got. However, you might find yourself in a situation where there are several things that look similarly risky in your project, and that can confuse anyone trying to figure out where to start. The secret is: it doesn’t really matter where you start, as long as you work towards reducing risks. This also means that once you start working on a particular feature, you should focus on that feature until you finish. That way you’ll have reduced the risk quite a bit. The importance of this, is that you might sometimes want to work on complimentary features that won’t help reduce risk, and at the end of the day, you’ll have accomplished nothing because you didn’t focus on what’s really important.
Once you’ve got your base feature, you’ll want to start building over it. That means, you’ll have to find all sorts of relationships between your base feature and the rest of the features of your program. After you’ve identified these relationships, you’ll have to pick another feature that will help you both reduce risk in your project, and compliment whatever you already have.
Remember, sometimes the best way to write great code, is to hold off on writing code for as long as you can, and focus on creating a great design instead. A great design will always lead to great code, and great design also leads to great software, which is ultimately what clients are paying for. Clients couldn’t care less about your code, they want their software to fit their needs, and to do what they want it to do, so it’s always important to remember that great software isn’t only great code; it also requires a great, intuitive design.
