Well, BAD code makes me uncomfortable.
When I start to write a piece of code, I tend to focus on the functional part of the problem. To just actually solve the problem at hand. That is simply step 1 of development. This is also the most important step. When you write code that doesn't perform the function it is supposed to, then it is literally worthless. Less than worthless actually.
So, now I have a piece of code. Chances are, I am not happy with it. It really makes me uncomfortable. There might be some ugly/non-descriptive variable names, some large methods, incoherent classes. It itches. My stomach turns a little. Things have to be simple, the code should flow naturally. The amount of WTFs should be low. I am not intelligent enough that I can afford having complex code. If it was hard to write, it will be infinitely harder to read later on when I have to track down some obscure bug.
So I start improving the code. Split out a method to simplify a complex piece of code. Improve those variable and method names. Sometimes I remove good chunks of code only to be replaced by some more elegant and simpler piece. Maybe there is a piece of existing code that needs some love. Sometimes there is an ugly piece of code that won't budge. It is the nature of the beast. In such cases I try to be as explicit as possible documenting the piece. I usually try to write as little documentation as possible. I find that when code is well written, it is self explanatory.
Sometimes it is really the design that makes me uncomfortable and I have to refactor large chunks of code. I won't hesitate to do it immediately. It will be worth it in the long run.
I keep doing this until I am happy with the overall quality. The design is right, methods are not too large or too small, no unnecessarily complex pieces of code, no magic numbers etc etc. This makes me happy. The uncomfortable feeling is gone. Now I can ask my colleagues to review what I have written and hopefully they have some insight in how I can improve my code.
Be humble. Be open. Be uncomfortable.
Friday 4 November 2016
Thursday 17 March 2016
The creative process of software development
This week I faced a technical challenge. One of the modules of an application I have developed didn't behave as expected. Well, in one scenario it works as expected, but it fails miserably in another.
So I started isolating and debugging the code the find the root cause. It's a pretty small application so that didn't take very long. But looking at and playing with the code didn't provide me with an easy solution. It felt like a brick wall. All kinds of complex possibilities kept popping up in my head but they all felt out of place. Big. Clunky. Inappropriate for this particular problem.
I was nearing the end of the day so I decided I'd go home and have a good night's sleep. Usually just taking my mind off a problem gives me the answer. Amazing how the brain works!
While it did give me some new insights I still couldn't mold them into a simple, elegant solution.
Had a couple of meetings. Had lunch. More new insights. Still no solution.
That's when I decided I had to really take a step back and take a different approach. So I closed my laptop, took pen and paper, put on some good acoustic rock and started to design this piece from scratch. Withing 30 minutes I came up with a solution that satisfied my search for elegance and simplicity. Within another hour I developed and tested this solution.
So in the end it took me about 90 minutes to design, implement and test this new solution. Should I have started with and pen and paper in the first place? I don't think so. Because I was working at it for about a day already and had a couple of good new insights I had a pretty good view on the various use cases and requirements. Without this previous investigation I wouldn't have gotten to the solution I have now.
Where would I have gotten if this didn't work either? I would have probably started drafting a question on StackOverflow. Drafting a good question takes a lot of thought and preparation. You have to really understand the problem to be able to ask a proper question. And in this process lies the answer. Only a fraction of the questions I want to ask on SO actually end up being asked. Most of the time I come to a solution myself just by the process of investigating the problem to form the question.
The takeaway for me here is that it is indeed a creative process. Sometimes you have to step back to see things clearly. And that is almost always worthwile to research further before implementing that big, ugly solution. Because usually it can be solved more elegantly. And that always pays off in the long run.
So I started isolating and debugging the code the find the root cause. It's a pretty small application so that didn't take very long. But looking at and playing with the code didn't provide me with an easy solution. It felt like a brick wall. All kinds of complex possibilities kept popping up in my head but they all felt out of place. Big. Clunky. Inappropriate for this particular problem.
I was nearing the end of the day so I decided I'd go home and have a good night's sleep. Usually just taking my mind off a problem gives me the answer. Amazing how the brain works!
While it did give me some new insights I still couldn't mold them into a simple, elegant solution.
Had a couple of meetings. Had lunch. More new insights. Still no solution.
That's when I decided I had to really take a step back and take a different approach. So I closed my laptop, took pen and paper, put on some good acoustic rock and started to design this piece from scratch. Withing 30 minutes I came up with a solution that satisfied my search for elegance and simplicity. Within another hour I developed and tested this solution.
So in the end it took me about 90 minutes to design, implement and test this new solution. Should I have started with and pen and paper in the first place? I don't think so. Because I was working at it for about a day already and had a couple of good new insights I had a pretty good view on the various use cases and requirements. Without this previous investigation I wouldn't have gotten to the solution I have now.
Where would I have gotten if this didn't work either? I would have probably started drafting a question on StackOverflow. Drafting a good question takes a lot of thought and preparation. You have to really understand the problem to be able to ask a proper question. And in this process lies the answer. Only a fraction of the questions I want to ask on SO actually end up being asked. Most of the time I come to a solution myself just by the process of investigating the problem to form the question.
The takeaway for me here is that it is indeed a creative process. Sometimes you have to step back to see things clearly. And that is almost always worthwile to research further before implementing that big, ugly solution. Because usually it can be solved more elegantly. And that always pays off in the long run.
Subscribe to:
Posts (Atom)