being a solo founder

So it’s been a while now since my last post and also since I decided to go solo and start out on business for myself. I’m not 100% sure that the former is due to the latter but it most definitely has had an impact. Writing posts is actually a good healthy habit that I have somehow managed to remove from my diet, and to be honest, has probably been to the detriment of creating my own business overall. The fall-off was mainly to do with the fear of writing about stuff that either A) Seems obvious or B) that no one wants to read about. I’ve now got myself over this by simply thinking who cares!

Photo by Kevin Dinkel

Given the above it’s with great pleasure that I present “The fuckwits guide to starting your own business“. This will probably turn into a more what-not-to-do set of posts given my success rate but it’s a case of you’ll get what you get.

First up. Going solo. That is, being a solo founder.

If anyone has not read the stuff by Paul Graham and so the idea has not been force fed that this is kind-of seen as a bad idea then let me tell you it is. Never do it if you have the option of getting someone on board with you, and this is as close as I can bring myself to say don’t bother starting up unless you have a co-founder – yes it’s that important. Unless you have the complete and total discipline to avoid getting sucked down the tar pit of either A) working too hard on the product development or B) working too hard to customer development, then it’s important to have the perspective granted by having more than one founder. I’d imagine that most developers with suffer from (A) more so than (B), and I’ve known that I’m suffering from (A) for quite some time and yet I continue to sink in the tar pit – I’m almost hoping that vocalising it jolts me into action (it didn’t with my last blog post about the very same thing though).

It was hard for me to even suggest that starting a business without a co-founder just shouldn’t be done, as invariably it’s never that straightforward and, in my heart (not head), I think it’s better to start something than nothing. Before deciding to go solo I had been down the rabbit hole of attempting to start a business with others but it always failed to materialise. 99% of the time the reason it failed to even get out the starting blocks was that the other folk were often not willing to take the risk that was involved of possibly having no meaningful income (by which I mean closely matched to their current income) for an extended period of time – possibly more a British (Scottish?) problem.

OK negativity aside what can you do to make it work? Obviously I don’t know or I wouldn’t be failing so miserably at it. However, here are the steps that I’m about to take moving forward:

Be more accountable. I’m currently pretty disciplined on the number of hours I work – I use a timer to ensure that I do enough hours in a day. However a fellow startup founder Lee from icmobilelab.com suggested an accountability buddy! This struck me as a good idea but I felt I had to take it a step further and use this blog to make my accountability a bit more public rather than depending on a single person.
Segment time better. Be more specific about how I spend my time during the day. So something like 8am-10am software development, 10:15am-11:15am write blog post, 11:30-13:30 customer development, and so on. I’ve tried this in the past and if memory serves me correctly it works well – this blog post is sort of evidence of that! Obviously there are days where this becomes harder to organise but it should be the exception rather than the rule.
Get out and speak to people. Potential customers here are the obvious choice but it’s worth meeting other founders or investors even just to catch up. I want to prevent myself from going dark for extended periods of time as it’s never a good idea.
Blog. People like hearing about what other folk are doing so I should do it more – many Scottish people have a curious trait of enjoying seeing others failing, so there’s always an audience! Also developers love telling people how their way of doing stuff is WRONG, so again, even with technical articles, always an audience.

Anyway, shit, over my allocated segmented time for this. Don’t worry going to pencil in another hour for Monday! Maybe more details of what I’ve actually created. Over and out.

The S in SOLID

Right, I’m back onto the SOLID principles again, I apologise to those who are bored of this.

So the other day I was listening to the most recent Scott Hansleman podcast with Uncle Bob Martin where the conversation was about the recent handbag fight between Bob Martin and Joel Spolsky – as I discussed in a previous blog post. In this podcast Bob Martin talks about an issue Joel Spolsky raised with him on the StackOverflow podcast #41. An extract from the discussion from the StackOverflow (SO) podcast #41 is given below:

Spolsky: Bob, can you explain again the Single Responsibility principle? Because I don’t think I understand it right.

Martin: The Single Responsibility principle is actually a very old principle, I think it was coined by Bertrand Meyer a long time ago. The basic idea is simple, if you have a module or a function or anything it should have one reason to change. And by that I mean that if there is some other source of change… if there are sources of change out there one source of change should impact it. So a simple example, we have an employee, this is the one I use all the time…

Spolsky: Wait, wait, hold on, let me stop you for a second. Change, you mean like at run-time?

Martin: No. At development time.

Spolsky: You mean changes of code. There should be one source of entropy in the world which causes you to have to change the source code for that thing.

Martin: Yeah. That’s the idea. Do you ever achieve that? No.

Martin: You try to get your modules so that if a feature changes a module might change but no other feature change will affect that module. You try and get your modules so partitioned that when a change occurs in the requirements the minimum possible number of modules are affected. So the example I always use is the employee class. Should an employee know how to write itself to the database, how to calculate it’s pay and how to write an employee report. And, if you had all of that functionality inside an employee class then when the accountants change the business rules for calculating pay you’d have to change the employee, you’d have to modify the code in the employee. If the bean counters change the format of the report you’d have to go in and change this class, or if the DBAs changed the schema you’d have to go in and change this class. I call classes like this dependency magnets, they change for too many reasons.

Spolsky: Is that… how is that bad?

I kind of feel the same as Joel with this one and I’m afraid that Bob is not really convincing me here. Why? Let’s pursue an example for a second.

Suppose that I’m creating a class that outputs a file. In this class I extract data from a database, convert various bits of the data, then output this data to a file. So how many reasons has my class got to change? Well it looks like 3: the database can change, how I convert the data can change, and how the file is output can change. Hence according to the S in SOLID, each of these operations should be contained in a separate class. Let’s just remind ourselves what the S in SOLID stands for:

A class should have one, and only one, reason to change. [1]

Now if I am forced into making changes to either the database, data conversion, and file format, I make the changes to my class. What is wrong with that? I just compile the project again and distribute the binary. Simple. I can’t see any benefit in breaking this class up into 4 separate classes, there just seems no point, but according to the SOLID principles there is. Arguments from Bob like “Yeah. That’s the idea. Do you ever achieve that? No” are nonsense. It clearly undermines the need for such rules in the first place. There is no point having rules if you are not going to stick to them. Fudging a rule every time it doesn’t fit your argument implies that the rule doesn’t make sense in general.

The discussion in SO #41 then moves on to the WordPress plugin system where Bob comments on how having independent plugins are a great example of the single point of responsibility (I must stress it was not Bob’s example, he just went with it). Eh NO. I think that it sometimes becomes easy to forget what the S means. Let me just state it again: A CLASS should have one, and only one, reason to change. The plugin itself, which is represented by a class, may have lots of reasons to change. Again in the subsequent Hansel Minutes podcast Bob uses the term module, in the sense of say a jar file in Java or a dll in .NET, to describe building a set of components that adhere to the S in the SOLID principles. This is once again deviating away from the actual meaning of S.

OK, am I being pedantic about the definition? I don’t think so. If it doesn’t mean what it says, then change it; there are people out there that will follow these rules blindly, and having such a specific definition only encourages this.

I think a far better rule would state that a class should only be responsible for a single task, in my example that task is creating the file. This is completely different from a class that has only one reason to change. OK, it’s a lot less specific, and maybe harder to judge, but any decent programmer will have a feel for what a task is. Not only does this seem like a more sensible option, it’s what the plugin and the module argument ostensibly encourage. It seems to me this is the only true generalisation you can extract from Bob’s arguments and I think it would be much better if this is what the rule suggested.

Don’t get me wrong, there are times when you want a class to only have one reason to change, this is especially true when you are developing a framework where the source code is essentially immutable to the outside world, in this case class design becomes far far more important. However the SOLID principles are intended as a set of rules for every programmer to use, and as it stands, I’m sure that the S is causing more confusion, code bloat, and misguidance than it is providing benefit to those adhering to these rules.

Having rules are a great idea, but they also encourage people to follow them word-for-word. It’s easy to say they should not be followed religiously, but I’m sure that is what is expected. This coupled with the developer with poor judgement, little experience and lots of blind faith, can leave us all wondering why we are even entertaining all this.

References

[1] http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

is it ok to not ask questions?

First, excuse the inherent contradiction in the title! Now, with the recent rise of stackoverflow.com as a programmers favourite dynamic and responsive encyclopedia, I find myself questioning my own behaviour.

Why? Well, I find that I almost NEVER ask any problem-based programming related questions to my peers.

Don’t misunderstand me here, the amount of stuff I don’t know is literally unbounded, it’s just that I will always work away at a problem until I have found the solution myself. I’m pretty sure that I didn’t always do this – I can vividly remember asking a friend with whom I worked with years ago many many programming related questions. Thinking back to those times though, it almost felt like I was cheating asking so many questions.

However, in the last 5 years, much of the development work I have undertaken has been as a contractor. In this setting I literally had no-one to ask. So what did I do? Well I just spent the time researching the problem, figuring out details, and then tried to use what I had learned to solve the problem – where the range of problems encountered ranged from the trivial to utterly complex.

This habit of not asking questions has continued with me. Even on a recent project I encountered several issues that literally had me stumped. Yet with a lot of effort and hard work, I got something that worked in the end. This, maybe wrongly, leads me to believe that those who ask a lot of questions are just not willing to put this kind of effort in – I suppose it’s that or they are just not capable! Or maybe they just prefer to economise their effort! Myself, I just think it seemed much easier to ask, and so that’s what I did. But that really just boils down to laziness. Right?

What can we tell from those who ask a lot of questions and those who ask none?

Despite my previous remarks, I think it’s easy to see why asking questions is a good thing: it saves time, builds communities, and most importantly it allows you to benefit from other people’s experience. That said, I feel that a developer who has the ability to free think, and “discover” a solution is extremely valuable – you may not always be in a position to find an answer to your burning question, especially if it is highly tied to the business logic of your application. I’m sure many of those people who ask the most trivial questions would benefit from the process of finding their answer, rather than being given it on a plate at the likes of stackoverflow. Is the success of stackoverflow the first sign of the dumbing down of programmers or is it the start of collective knowledge transfer that can only benefit our whole field?

The link between free thinkers and those who do not ask questions is not an if and only if relationship – anyone with any experience of tutoring students will know this. Many people who do not ask questions actually don’t have a clue (and maybe never will). You see this all the time with certain students; they never say they have a problem and they don’t ask questions. Then you see their exam results and think WTF.

This leaves me with a problem though: I don’t want to say that all free thinkers don’t ask questions, and I know those who do not ask questions are not all free thinkers. How do you figure out what is what? Mmmm, maybe I will just leave that as a question 😀

some top tips to piss off your colleagues

Every day you stumble into work and go about your daily routine. You’re reasonably sure that you’re a model work colleague and everyone likes you. But this is pretty boring right? So from this day forward you decide to make other people’s life a misery. Here are a few handy tips guaranteed to help you with this.

(A short note: in case confusion ensues the tone of this article is meant to be somewhat tongue-in-cheek! And please let me know of any annoyances that I may have missed in the comments 🙂 )

Constantly receive incoming phone calls: to be honest it doesn’t even have to be constant, just enough to make it appear constant to those sitting around you. I have no real problems with people talking around me or even playing music out loud (as long as it’s not all the time), but the torture of constantly hearing a one-sided conversation is exasperating. For maximum effect, I suggest you have a really bad ringtone, and make outgoing calls with regular frequency as well.
Take that chicken curry back to your desk so everyone can smell it at lunchtime: I can’t work out whether this is the thing that annoys me most. There is nothing worse than sitting down to do some work and some dude slaps his lunch down on the table 2 feet away. OK, eating certain things at your desk is fine, but there are others that should just be outright banned, and it doesn’t take a genius to figure out if you are eating one of those things. Or maybe it does! My suggestion to obtain the maximum effect with this one is to leave it sitting on your desk for a bit to “cool down” prior to eating it.
Constantly ask people the same questions (or make the same mistakes): I know this one affects more than just me – I will elaborate. Imagine sitting next to someone who constantly asks you the same questions about how to do something. OK, at first they were new and you answered with glee, but it’s been two years since this person started in the job and they still ask you how to the most simple tasks (like how do you build the software). Not only that but when you tell them they always experience a problem, the same problem, and ask you why it’s not working. This is guaranteed to make people start muttering under your breath at you as soon as their name leaves your mouth. Note: This works best if you don’t say their name too loud at first and just lightly let it drift off your lips. This will give the “pink panther effect” where they will gradually think they are going insane. Those who cannot learn from history are doomed to repeat it.
Find out the names of new buzz technologies, then constantly suggest the inclusion of such things in your app, especially if they are not relevant: remember you don’t need to know what the new technology does or the advantages/disadvantages of it – in fact it’s better that you don’t understand what they are, this heightens the effect. For example, say you want to use AJAX in your legacy desktop COBOL application. To make this even more powerful don’t listen to people when they try to tell you that it’s not relevant, just state “it is” and then bring it up again in the next meeting.
If you’re a manager, have favourites: this is just soooo cool to do if you are a manager. There is literally no better way to piss off those people who are not on your favourites list. If you want people to really talk about you, this is the one to go for. For added value, place all those that you don’t really like in a maintenance team, fixing all those pesky bugs that your favourites create.
If you’re not a manager, and your manager has a favourites list, try to be on it: everyone hates a brown nose and this will easily get you straight to number one spot of your colleagues diatribe without a shadow of a doubt. For this to be especially effective you have to be on that list because you know nothing, but are not going to let that get in the way of your career. Once you are on it though, try to do things that you know will annoy other people, but your boss will let you away with because you are his favourite, e.g. show up late for stuff.
Keep meetings running on longer than they should: if you think a meeting is nearing its conclusion, try and extend it for at least another 30 minutes – you can do so by going over the same points that were discussed in the previous hour of the meeting.
If you’re a manager, send programmers on courses they will really really hate: one course that will probably do the trick is communication skills. Ensure that the course has lots of role playing, and drops the average programmer waaaaaay out their comfort zone. To really rub it in, make them write a report about it when they get back. Then when they give you the report, make it obvious that you are never going to read it anyway.
Make people feel completely uncomfortable if they have to ask you a question: the key to this is to make them feel STUPID. Some possible tips with this are to sigh loudly when they get to your desk; don’t make eye contact when they speak to you, just keep typing and looking at your screen while talking to them; speak to them as condescendingly as possible, phrases such as “it’s obvious!” and “everyone knows that!”, normally hit the mark; and finally show disdain toward any ideas they come up with. Also, never finish the conversation by confirming that they have actually understood what you have just said, just sit in silence and see how long it takes for them to realise the conversation is over. Essentially you are trying to be as unapproachable as possible.
Occupy other people’s space: just start to gradually leave pieces of paper and books on the person’s desk next to you. Don’t limit it to objects though, try to put yourself in their space as well. Leaving empty mouldy coffee cups, and half eaten food will likely yield a reaction, just don’t let this stop you.

programming language obsession makes you look stupid

It appears that many people seem to have too much of their life wrapped up in a particular programming language. You only need to look over at dZone, Reddit or Digg to see this fandom in all its glory. All too often we find articles about why such and such a programming language sucks. However, just because a language sucks for one (or a couple) of particular reasons, it doesn’t mean it is not useful in general. It’s like me saying computers suck because they crash. However, just because my computer crashes from time to time doesn’t mean it’s not useful.

I just find the whole religious aspect to a language rather pathetic. The result often leads to the inappropriate choice of language for development of an application, simply because the individual’s voice that is heard the loudest makes the decision. Ok, if any language will do then just go with whatever you are comfortable with, but stop yourself bitching about other people’s choice of language.

For example, the number of times you hear people saying dynamic languages are no use, for a plethora of reasons, is stunning. You would think that no one had ever developed anything of reasonable size and scale in these languages. It’s not as if most of the largest websites on this planet have not been written in PHP/Python/Ruby, yet you still read articles where people are saying where such a feat is likely to lead to catastrophe. Stop doing this it makes you look stupid.

The same can be said for those that diss Java. OK, I think it’s possibly a poor choice for those considering a startup web business (basically if you are going to be considering shared hosting Java as an option on this platform is nonexistent), but there are many places where the use of existing libraries written in Java make it the ideal choice for an application. An example of this can be seen in what I’m currently working on, which is an application that uses constraint programming techniques. There are a few such libraries in other languages but the most mature and feature rich (and free) are in Java so sense dictates you use Java.

Essentially my bug bear boils down to people choosing a language for the wrong reasons, more often than not due to blind faith rather than education. Don’t just use a language because it is popular, use it because it best fits the job needing done. Popularity can come into it though, because at the end of the day you might wish to tap into a large set of existing programmers, or you may want to attract the brightest young talent who want to work in what’s popular/new. Just don’t let it be the only thing that dictates your choice.

Unfortunately, regardless of however many blog post or articles people read and write, I feel that we are never going to remove this inherent language evangelism. Maybe the industry would be in a far better position if we were all language agnostic. Can you imagine how much more work would get done if people spent the first two months of a project actually doing work rather than arguing about what language it should all be written in.

the secrets to obtaining a happy programmer

The ideal working environment for a programmer is an topic which has received considerable attention. What we (programmers) normally idolise after are, amongst other things, (multiple) large monitors, Herman Miller Aeron chairs, private offices, break-out rooms, and, of course, the best tools for the job. Joel Spolsky, the Godfather of programmer satisfaction, went even further and gave us the Joel Test for assessing a prospective employer. However, are the above all that it takes for programming nirvana? Probably not.

First up, I would love to experience an environment where each and every one of the things mentioned above was in place. However, in my career so far, I have yet to work in an environment where these things have been par for the course, and maybe I would be content with such a work environment. I’m pretty sure I wouldn’t though. Not because these things aren’t good but there is a vital ingredient that can make these things irrelevant.

So what is this ingredient? Well it’s FUN, or lack of it. Yes a fun workplace! I’m sure there will be those out there that think work isn’t supposed to be fun, well ask yourself why. Fun doesn’t necessarily mean that no work gets done – the contrary in fact. It’s a place where like minds can sit and create and innovate about things they find interesting. Now here is our first problem.

Essentially fun is the environment combined with the people. However, all too often we find ourselves in an environment where the people are not like minded. What surprises me most is that in an office full of software developers only a handful (or less) may be genuinely interested in software development. I’m not sure if I have just worked in the wrong places – however friends have confirmed a similar problem. It’s not simply that you couldn’t sit and talk to certain individuals about software development, it’s that you pretty much had difficulty talking about anything. It was often like talking to a baked potato.

For me this not just a job, software is one of my top three interests (along with music and cycling, for those who are nosey 😉 ). Wouldn’t it be nice if an employer could respect this – I’m not saying they all don’t, but most don’t, it makes it easy to see why Google attach such an importance to their culture.

All this is not to say that I think we should all be the same, it may be the case that you have to turn good people away because they simply don’t fit your culture. I think the culture is that important. This has been shown in the past by the likes of Richard Branson whose music empire started by providing an environment (in essence a community) where both the employee and consumer found it fun to gather in his record shops. Certain universities have also found this valuable over the years.

So essential we can have all the goodies we like, but unless we are working with people that are Smart and Gets Thing Done (or preferably Done and Gets Things Smart), and fit our culture, then maybe we are never going to reach our programming nirvana.

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.

Return from if statements as quickly as possible.

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

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:

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.

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; } }
function isStringEmpty(str){ if(str === "") { return true; } else { return false; } }
Just remove the if statement completely:
1 2 3
function isStringEmpty(str){ return (str === ""); }
function isStringEmpty(str){ return (str === ""); }

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:

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.

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
}

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.

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;   
}

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; //}
//function thisReallyHandyFunction() { // someMagic(); // someMoreMagic(); // magicNumber = evenMoreMagic(); // return magicNumber; //}

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):

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.

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?