Some time ago, I've answered to a job interview question which was sounding more or less like: «suppose you have 20 minutes to talk to an audience of junior developers about what have been the lessons you learned from your software development experience, and resume that in three points, about what a good developer shall do. What would be your advices?»

Thinking top-down

First, when you write your code don't start from the implementation, but start from the client code. Today it is popular to speak about Test Driven Development, and how writing test code first (which is client code), drives you to a better design. In the same way you can write your back-end services starting from the front-end, from how the user interacts with the UI, and letting the implementation details to be driven from it. The internal design should emerge from the use cases, not viceversa. So, testing software early not only drives to more reliable applications but, same importantly, also leads to much better code: easier to understand, to extend and maintain. It is not a detail: in the software industry the code is your product!

I appreciate more a developer who writes code which is easy to follow, rather than developers who can easily understand messy code. Messy code comes from the bottom-up approach. The ability to deal with messy code, comes from the habit to write and deal with it. Real good developers are the one who developed a fine sense of the code smell. A good developer do not write code unless it is strictly necessary, and this is much easier if you start from the abstract idea.

Imagining the "model" at first means to predict what you are gonna need. It brings in constraints, and require you to take decisions, which will likely reveal to be wrong later.
I learned this when I started to work in eclipse. In eclipse you use a variable (which doesn't exist yet!) in your method, eclipse underscore it in red to say that there is a compilation error, then you do a "quick fix" and let the IDE to declare the variable for you. You call a method which do not yet exist, and let the IDE to implement the stub. This reverses your way to think. You will never write a useless method or variable again (at least this risk will be drastically reduced, and with some discipline you can easier keep things clean).

Instead of thinking before on the the details, you can focus on your business and write code which explain what your method is doing. And only after you will write the code specifying how to perform the functionality.
Starting focusing on a more abstract level helps making better applications for the users, and the code quality will also benefit.

For the notice, Wikipedia says that "bottom-up programming approach which is common in object-oriented languages such as C++ or Java". I agree with the guy who is defining this a «complete utter bull dung».

Writing readable code

Try to keep your code speaking, let the code be self explanatory, it's not that difficult... if you find yourself writing much comments to explain what an algorithm is doing, probably it means that your code is not readable. Comment in source code is documentation for developers; but the code itself, if it is understandable by another developer, is the best documentation. Avoid putting logs everywhere: it makes the code confuse, and difficult to maintain (how many times code changes and logs do not reflect anymore what's happening?). Put log statement in the strategic points: logging is a part of your application and also that should be carefully designed and thought as a feature. Don't put "debugging" everywhere, logging != debugging. Debug with your IDE, and write tests; it's hardly the case when you can understand what went wrong just from trace logs.

Once the code is written, it is going to be read dozen of times, and this is why it is so important that code is easy to read. Personally I prefer code which is understandable and performs well, over code which is messy and (maybe) perform super-fast. Most of the time messy "optimized" code is slower than simpler and more straightforward code.

Handling properly error/exceptional conditions

It looks like this is one of the hardest things to learn from software developers. And it's the source of many bugs. It's simple as that: catch the exception you can manage, and let the other pass through. Avoid "catching-and-rethrowing", avoid exception swallowing, and other amenity: there are plenty of articles about things you'd better never do. This one is quite comprehensive: Exception Handling Antipatterns. Make sure your software not only works well when everything goes fine, but also give the proper messages when something bad happens. This will also reduce the need to dig in log files just to discover that "a server is down" (when your application could just nicely tell that to the user, or inform the administrators!), and reduce the habit to have so much code for debug log statements.

Writing code in TDD also helps with this. Finally try to think "what could go wrong? and how my software will react?" before saying you've completed your tasks. Remember how do you feel when you get a cryptic blue screen, and how Windows gained the name to be a very buggy OS.

Don't become a bluescreen author.

Conclusions

I don't know if this is a good answer to the question. But it reflects quite well some of the things I feel very important when I write my code, and that's why I decided to write about this topic here.
And no, the interviewer didn't hire me :)


8 Responses to “Top 3 things to do to make better software”  

  1. 1 pm

    Great post. I completely agree with you. I’ll go to read all of this links.

  2. 2 Luigi

    Thanks pm. Just found this nice link from your blog:
    TDD from starting from user stories – a top-down style which seems in line with the above post.

  3. 3 Riccardo Pasquini

    Great Luigi!
    I would like to add one extra point:
    The need to share the dictionary between the model and the customer to improve the understanding of the problem

  4. 4 Alex

    He didn’t hire you because of the answers or something else?

    I suppose that is critical…

  5. 5 Luigi

    I don’t know, probably they evaluated all the aspects, and all other candidates. There may be many reason in driving decisions when to hire a guy or another one. BTW, I had an optimal impression about the company. For sure they have a good selection process, I had to answer also on many technical questions. I enjoyed speaking with those guys.

  6. 6 jkilgrow

    You mentioned that this was your answer to an interview question. Did you get the job? Did the prospective employer agree with your answer enough to hire you? If not, is it possible that you might be wrong about your opinion of TDD?

  7. 7 Luigi

    It is always possible that I am wrong; and I am ready to learn where.

  8. 8 Philopator

    Great post.

    I would just add my all-time-favorite: when writing the code ALWAYS maintain consistent level of abstraction. This is critical to able to intellectually manage and reason about the code.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Calendar

April 2010
M T W T F S S
« Jan   May »
 1234
567891011
12131415161718
19202122232425
2627282930  

Follow me

twitter flickr LinkedIn feed

Subscribe by email

Enter your email address:

Archives


Categories

Tag Cloud


Listening