Taking the PAIN out of coding


Over the years, I have learnt some tricks and picked up some lessons while writing code. Most were learnt the hard way, so I decided to share a couple of tips on how to avoid development pitfalls.

Meticulous Planning and Design

One of the most difficult lessons I learnt in software development was not to rush into code; I used to jump impulsively into software projects and start hacking away at code without planning fully. And as you can bet, the thrill of coding soon evaporated when I got bogged down by messy code. Sadly, many projects of mine met their nemesis this way.

Now, I am just too lazy or maybe too battle-scared to do that; I mostly write out a high level system design document (usually a single page or two) describing all the major features. Next, I run through everything to know that the various components and interfaces are logically valid and try the edge cases. Only when I am satisfied with this do I start writing code.

Alhamdulilah, I think I write cleaner, more modular and better designed code this way. For example, I recently had to extend an experimental framework I wrote a couple of months back; surprisingly I was able to make all major changes in less than two hours. Better still, nothing broke when I ran the framework again!

A dev lead once told me coding is the easiest part of software development… I think I agree with him…

Do it fast and dirty, then clean up

I started using EmberJS last year for a web project. EmberJS is a really cool framework and reduces the amount of boilerplate code you have to write: it’s so powerful that some things seem magical. However, EmberJS has a really steep learning curve.

As usual, I was trying to write perfect code at my first attempt, did I succeed? Your guess is as good as mine. I got so frustrated that I started hating EmberJS, the project and everything remotely related to the project. :)

Before giving up, I decided to have one more go at it; my new approach involved ignoring all standards and good practices until I got something to work. And that was it, I soon got ‘something’ that looked like a working web application running. One day, while working on the ‘bad’ code, I had an epiphany. In a flash, I suddenly knew what I was doing wrong. Following standards and practices was relatively easy afterwards.

Looking back, I realize that if I was bent on doing it perfectly at the first go I most probably wouldn’t have gotten to this point. Oh by the way, EmberJS got a new release so my code is obsolete again. :P

Clean up the code from step 2 above X more times

This is a part of development I don’t think I really like but it is essential for maintenance. You have to go back through the code (yes, your code; you ain’t gonna make life miserable for the developer inheriting your codebase). Refactor all duplicated, extraneous and obscure pieces of code ruthlessly. Most importantly, improve the readability of the code (yes, readability is REALLY important – make it read like a good novel if possible à la Shakespeare or Dickens).

I also keep a running list of all the hacks I make as I go about writing code in step 2; this list comes in handy at this stage and enables me to go straight to the substandard code pieces and fix them up.

Use a consistent coding style

I recently noticed that my coding style was inconsistent across my projects: variables names were either under_score or camelCase while method declarations used brace-on-new-line and brace-on-same-line approaches.

The problem with this approach is that it breaks up my flow of thought and makes speed-reading code difficult. Now, I choose a single style and stick to it throughout a project – any style is fine provided I use it consistently.

Scientific Debugging

I came across the term ‘scientific debugging’ while blog-hopping and it has stuck in my subconsciousness ever since. Identifying bugs can be a challenge: for small projects, I just try to figure out where the bug might be and then check for this. However, this approach does not scale, I wouldn’t randomly guess on a 5000 line project.

Scientific debugging is a systematic process: you make hypotheses about the likely causes of the bug, make a list of places to check and then go through this systematically while eliminating entries. You’ll most probably find the bug with less effort and without running through the entire list.

Project Management

I rarely used to track how much time and effort I put into my projects; I would just code and code and code. Now I know better, I estimate how many hours I can put in before, during and after each project. I try to use Agile (although, I use a simple list + pomodoro too) for project planning, task management and effort estimation. It is now trivial looking up my project status: implemented features, issues list and proposed features.

Testing

I tried my hands at TDD last year and I felt it was just a way of doing too much work for coding. While I might be wrong about TDD, I think it’s essential to have a solid testing process in whatever project you’re doing.

Test, test and test: run the gamut (if possible): unit, integration, functional, stress, regression etc.

Enough said… I have dirty code to polish. If you did find some of the points useful, please share your thoughts and ideas.

Related Posts

  1. Symptoms of Software Rot
  2. So you want to become a better Programmer
  3. Clean code, Dirty code
Advertisements

The language series: PHP


I think PHP is disproportionately targeted for rants; it’s the language everyone loves to hate. Despite the proliferation of posts that list the 1 trillion things PHP does wrongly, more than 70% of all websites run PHP on their servers. Even more interestingly, ‘better’ languages like Ruby are below PHP in the TIOBE index ( a language ranking metric). Definitely, PHP must be doing something right, no?

Personally, I am pretty much indifferent to the language (or any other language for the matter); it does what it needs to do. Now, don’t start another debate around this post.

How I came to learn PHP

I had to learn PHP during my 6-month undergrad internship; I would have preferred a Java-related job however, after 6 weeks of extremely difficult job-hunting, I was ready to take up anything. I wrote lots of PHP code, lots of baaaaaad code – the type that makes you cringe, rant about PHP and scream at the developer. The only rule I didn’t break was using proper variable names; all other rules ( DRY, YAGNI, OOP concepts) were routinely chucked out of the window.

It wasn’t PHP that made me write bad code, it was rather due to my amateur software development skills – that was my first real-life software development experience. However, I got to write some fun code too Alhamdulilah; a cool timetable generating algorithm, do some Linux and toyed around with networking ( I dropped that afterwards).

The Bad Parts of PHP

All languages have flaws and PHP is no exception; here are some of the reasons why people say PHP is baaaad for your programming health :D:

  • The language wasn’t really designed but grew by accreting features. So it feels kind of clunky…
  • Built-in libraries and functions are inconsistent.
  • The naming convention is a mix of different naming styles
    • camelCase: getName() 
    • under_score e.g. array_combine()
    • joinedwords e.g. localtime()
    • modulename_function: libxml_clear_errors()
  • No Unicode support.
  • Slow; of course, what do you expect?

The Good

  • Huge libraries; PHP has functions for nearly everything you’ll ever need: regular expressions, URL parsing etc.
  • Awesome database support.
  • Familiar syntax; similar to the C/Java family.
  • Great community – the PHP community is sooooooo active.
  • Widely supported by hosting companies and is extremely widespread.
  • Easy to use:
    • Install WAMP/LAMP/XAMPP and get coding.
    • Low deployment and maintenance demands – you don’t need 6 months to launch :)
    • Easily integrated with most applications and frameworks.
  • Extensible platforms exist e.g. wordpress, Joomla, Drupal.

Developing in PHP

Most developers start out with Macromedia Dreamweaver and they write extremely long monolithic files that are poorly structured and organized –  ugly spaghetti code. Amateur developers don’t care for two reasons: little development experience and they get to build stuff. Ultimately, without improvement, these developers are responsible for the bulk of awful PHP code existing out there. There is little that can be done about this; however, if you have bad PHP code, please hide it until it’s improved. There are already enough rants on the internet…

Hopefully, you’ll realize the flaws in your development skills and leave Dreamweaver for an IDE (I personally think Netbeans is awesome). You’ll might go ahead to learn about, NoSQL DBs, ORMs and a couple of other good things.

Finally, maybe you’ll move on to other languages and come to see your old PHP code as ugly. If this happens, just don’t forget that  you’ve probably improved your programming skills by learning a new language so don’t blame PHP totally – you were a worse programmer before. Remember this before you start ranting.

Rating

6.5/10

Bjarne Stroustrup said: “There are only two kinds of languages: the ones people complain about and the ones nobody uses”.

Agreed that it’s not be the best language but come on, it gets things done. The language is way too popular today, has excellent support and helps you to get things done easily.

Do you like this post? Check out my earlier posts on C, Python, JavaScript and Java.