good practices

There are 4 posts tagged good practices (this is page 1 of 1).

programming just isn’t that hard!

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.

some thoughts on pair programming

In the last couple of days I have had a chance to do a little bit of pair programming.  In the past I have found myself being a touch sceptical of it all, but predictably I hadn’t actually done much.  So here are some thoughts from my recent experience.

Firstly, I must admit it was only half pair programming, in the sense that I was only an observer and not a driver.

I would say that my biggest concern with pair programming is I found it hard to believe that there would not be a drop in overall productivity with two people concentrating on the same task.  However, I’m beginning to think that, counter intuitively, this may not be the case, but it also depends on the task.

For example, when two people have a completely different skill sets and both skill sets are required for the job.  In my case, I knew literally nothing about the programming language we were developing in.  However, I had a fair amount of knowledge with regards to the “API” we were coding to (fair amount meaning I wrote it!).  As a result of this I knew what we were trying to achieve but just not how to achieve it.  In this situation the pair programming seem to go very well and I would suspect that the functionality was added to the code twice as fast as it would have been if any one of us had to do it alone. 

So what are the other benefits?  You generally always learn something when pairing up –   even if you have more experience than the other person.  For me, I learned that you could place a hash (#) in front of the number to specify the ascii value for a character, for example, #9 is a tab character.  This had passed me by for some reason, I mean I knew in HTML you could do stuff like &#33 to obtain an !, but I had just never thought about what it meant.  Now I understand!  You also get the benefits of seeing how someone else thinks, and you can learn a lot from that.  You might also gain “tips” for navigating the environment or valuable tools being used.

There are some downsides too.  When I was doing it the last couple of days I never noticed too many, but I can certainly imagine thinks like different personalities, strong opinions, and reluctance to participate, affecting things quite drastically. Here are a few that I think may annoy the driver, but as I wasn’t driving I don’t really know for sure.

First, as a navigator you sometimes notice tiny things like misspelt names, missed semi-colons, etc, and at the start I pointed these out pretty quickly.  However, I then thought to myself, maybe the person has noticed these things and was going to go back and change them when they finished typing the line.  So I just tried to stop myself interrupting too much – as I suspect someone who constantly points things out can get pretty annoying.  I also had to stop myself preaching my coding habits that don’t make a difference to functionality, that was harder though, as I pretty much have an opinion on just about everything 🙂 .  As for navigating, I’m sure someone that completely ignored your suggestions and coded away regardless would be extremely annoying.

I’m not sure that pair programming is THE definitive development strategy.  I’m certain that someone sitting over you while you are writing some form of input parser in which you are just running through the motions is almost pointless.  Also, when you have to think really hard about something, whether it be debugging a hard problem or some complex algorithm, someone interjecting all the time would be extremely off-putting.

So to sum up: pair programming definitely has advantages and with some careful planning it can be used to improve a projects quality, cost and time to launch.

7 ways to write beautiful code

I’ve noticed that the developer and designer community appear to be obsessed with lists. Is this for a reason that I have somehow missed? For example, over at dZone, 2 out of the top 3 most popular articles are lists: 15 CSS Tricks That Must be Learned and 10 Dirty Little Web Development Tricks – incidentally I liked both articles so I seem to have this obsession myself. OK this is not that many but hey I’ve seen loads of lists elsewhere. Anyway, I thought I would embrace this culture to feed my own addiction and I have detailed 7 (I was only going to do 5, and 6 was out as it’s not prime 😉 ) ways to write beautiful code.

First things first here, I’m talking about pure aesthetics, nothing else. As I have said previously, good code starts by being something other people find easy to read. In fact, Jeff Attwood had a blog post comparing coding to writing citing several sources. I urge you to take a look.

Anyway on to my list.

  1. Return from if statements as quickly as possible.

    For example, consider the following JavaScript function, this just looks horrific:

    1
2
3
4
5
6
7
8
9
10
11
12
13

    function findShape(flags, point, attribute, list) {
    if(!findShapePoints(flags, point, attribute)) {
        if(!doFindShapePoints(flags, point, attribute)) {
            if(!findInShape(flags, point, attribute)) {
                if(!findFromGuide(flags,point) {
                    if(list.count() > 0 && flags == 1) {
                          doSomething();
                    }
                }
            }
       }
    }   
 }

    Instead we can change the above to the following:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    function findShape(flags, point, attribute, list) {
    if(findShapePoints(flags, point, attribute)) {
        return;
    }
 
    if(doFindShapePoints(flags, point, attribute)) {
        return;
    }
 
    if(findInShape(flags, point, attribute)) { 
        return;
    }
 
    if(findFromGuide(flags,point) {
        return;
    }
 
    if (!(list.count() > 0 && flags == 1)) {
        return;
    }
 
    doSomething();
 
}

    You probably wouldn’t even want a function like the second one, too much going on (see point 7), but it illustrates exiting as soon as you can from an if statement. The same can be said about avoiding unnecessary else statements.

  2. Don’t use an if statement when all you simply want to do is return the boolean from the condition of the if.

    Once again an example will better illustrate:

    1
2
3
4
5
6
7
8

    function isStringEmpty(str){
    if(str === "") { 
        return true;
    }
    else {
        return false;
    }
}

    Just remove the if statement completely:

    1
2
3

    function isStringEmpty(str){
    return (str === "");
}
  3. Please use whitespace it’s free!

    You wouldn’t believe the amount of people that just don’t use whitespace – you would think there was a tax associated with using it. Again another example and I hesitate to say this but this is from real live code (as was the first example), all I have done is change the programming language and some function names – to protect the guilty:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

    function getSomeAngle() {
    // Some code here then
    radAngle1 = Math.atan(slope(center, point1));
    radAngle2 = Math.atan(slope(center, point2));
    firstAngle = getStartAngle(radAngle1, point1, center);
    secondAngle = getStartAngle(radAngle2, point2, center);
    radAngle1 = degreesToRadians(firstAngle);
    radAngle2 = degreesToRadians(secondAngle);
    baseRadius = distance(point, center);
    radius = baseRadius + (lines * y);
    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
    // Now some more code
}

    I mean I won’t bother putting an example of how it should be – it should just be sooo bloody obvious. That said, I see code like this ALL the time and so certain people do not find it that easy to judge how to use whitespace. Screw it, for them I will inject some whitespace into the example and it’s shown below.

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

    function getSomeAngle() {
    // Some code here then
    radAngle1 = Math.atan(slope(center, point1));
    radAngle2 = Math.atan(slope(center, point2));
 
    firstAngle = getStartAngle(radAngle1, point1, center);
    secondAngle = getStartAngle(radAngle2, point2, center);
 
    radAngle1 = degreesToRadians(firstAngle);
    radAngle2 = degreesToRadians(secondAngle);
 
    baseRadius = distance(point, center);
    radius = baseRadius + (lines * y);
 
    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
 
    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
    // Now some more code
}
  4. Don’t have useless comments:

    This one can get quite irritating. Don’t point out the obvious in comments. In the example below everyone can see that we’re getting the students id, there is no need to point it out.

    1
2
3
4
5
6
7
8
9
10
11
12
13

    function existsStudent(id, list) {
    for(i = 0; i < list.length; i++) {
       student = list[i];
 
       // Get the student's id
       thisId = student.getId();
 
       if(thisId === id) {
           return true;
       }
    }
    return false;   
}
  5. Don’t leave code that has been commented out in the source file, delete it.

    If you are using version control, which hopefully you are – if not why not! – then you can always get that code back easily by reverting to a previous version. There is nothing more off putting when looking through code and seeing a large commented out block of code. Something like below or even a large comment block within a function itself.

    1
2
3
4
5
6

    //function thisReallyHandyFunction() {
//      someMagic();
//      someMoreMagic();
//      magicNumber = evenMoreMagic();
//      return magicNumber;
//}
  6. Don’t have overly long lines.

    There is nothing worse than when you look at code that has lines that go on forever – especially with sample code on the internet. The number of times I see this and go ahhhhhhhhhh (I’ll switch to Java for this, as generics makes this particularly easy to do):

    1
2
3
4
5
6

    public static EnumMap<Category, IntPair> getGroupCategoryDistribution(EnumMap<Category, Integer> sizes, int groups) {
        EnumMap<Category, IntPair> categoryGroupCounts = new EnumMap<Category,IntPair>(Category.class);
 
        for(Category cat : Category.values()) {
            categoryGroupCounts.put(cat, getCategoryDistribution(sizes.get(cat), groups));
        }

    I’m not suggesting the 70 characters width that you had to stick to on old Unix terminals but a sensible limit like say 120 characters makes things a little easier. Obviously if you are putting sample code on the internet and you have it within a fixed width container, make it easier for people to read by actually having it fit in the container.

  7. Don’t have too many lines within a function/method.

    Believe it or not a few years ago now an old work colleague exclaimed that Visual C++ was “shit” as it didn’t allow you to have a method with more than 10,000 lines. I kid you not – well ok I can’t remember the exact number of lines but it was huge. I still see this time and time again where a function/method is at least 50 lines long. Can anyone tell me this is easy to follow? Not only that but it normally forms part of an if statement that you can never find the enclosing block because you are scrolling. To me anything over 30-35 lines is pretty hard to follow and requires scrolling. My recommendation is if it’s more than 10-15 lines consider splitting it up.

This is by no means an exhaustive list and I could have gone on longer – in fact my abolish the switch statement motto would have been number 8 if I had not already mentioned it before. However, it has to end somewhere but feel free to state your own annoyances and maybe I can update the post with some more.

Over and out.

bad software engineering – made easy

Often I find myself suffering from a chronic bout of “project fatigue” – I made this term up off the top of my head so don’t go to your doctor asking about it 😉 . However, it’s not the symptoms of this illness that concern me, it’s the consequences of getting it. So what is this “project fatigue”?

You may be one of the lucky ones never to have experienced this, but I know my close friends who also work in the programmer trade have suffered. It can onset at any time. It’s characterised by a morning or afternoon of doing anything but typing code into the computer, which can then be followed by days (or weeks) of doing absolutely nothing related to the work you’re supposed to be doing. And it all happens because you got tried/bored/frustrated/stuck with the project you are working on.

When you first start a project (or a new job for that matter) it normally has a euphoric feel to it. You charge in head first, and it’s brilliant, you are learning all these new things. You come in every day and after the obligatory email and quick favourites check you are straight on to coding away like a demon (or daemon). You’re thinking that “if I’m this productive and can get so much done, I don’t understand why it takes so long to finish things”. What you have forgotten about is THE FATIGUE.

So after maybe a month of working away night and day, it hits. Myself, I normally find it starts when I find out that the way I was doing something doesn’t seem to work. This inevitability means that some of the code you have written is now useless, and other stuff you have done really should be changed to accommodate the new design. To generalise, I would say that it causes you to do ANYTHING just to get the project done. This maybe because you either don’t have the time to let the fatigue pass, or that you are just so desperate to get off the project that anything will do.

What this means is that where before you were creating a design of your code to die for, you now just make sure that it “works”. This is where it becomes so very easy to do some bad software engineering.

For example, you think “I should really change that class/method to such and such” but you also are thinking “well I could just hack round it by doing something not so nice, as that is bound to be quicker”. When you start thinking like this you should ALWAYS make sure that you do the former rather than the latter, as much as it pains you to do so. Why? When you come back to looking at the software for a later version you will be glad you done it, and also it never takes as long as you think to do it the correct way.

So how can we avoid the fatigue? I really don’t know, maybe YOU have some suggestions? What I tend to find helps is leaving the code for a day or so and not think about it. Why not write a script! Obviously this “leaving it for a day or so” may not sit with your employer so well, but if he only knew that it would mean less bugs in the long run then it may be a different story. I dunno, as this line of thought doesn’t always work.

What I think is a far better option is to have good mentor. As I would imagine that about 98% of the fatigue is caused by a lack of motivation to finish or that you are stuck on a certain problem. Talking to someone about the work and resolving points that you are stuck on can be empowering. You can often be even more productive than just before the fatigue set in after a simple chat with someone – I often experienced this after a meeting with my supervisor when doing my PhD. It’s important to have the right person doing the mentoring though – as there are people that can make the situation worse by just plain confusing you or demoralising you with their “superior” knowledge.

So in the style of a counselling group, my name is Gregg and I’m suffering from project fatigue. What are your suggestions?