The Mad Bug Blog

This is a big one. Developers live in their toolset. Do you have a nice home for the developers, or do they desperately want to leave their nagging documentation tool and go get wasted at the pub?
If you avoid the following DON’T  (even if avoiding some of the DON’Ts ends up with double negatives) you’ll be on your way to happier, more efficient developers.

DON’T : Use any wiki other than confluence.

Confluence is the best wiki for developers due to it’s great code formatting options and easy linking.
The most brain-dead thing I’ve ever come across in my 10 years of dev was at one place they shut down confluence in favour of a document version control system called Objective. So instead of a quick to updated, indexed, cross linked wiki – we had Word docs describing technical architecture and processes. End result, almost nothing technical got documented because it was such a pain to write and impossible to find to read it.

DON’T : Use source control as business document control.

Here’s one to help out the BAs. You know what CVS, Subversion, Git and Mecuiral all have in common? They’re garbage at versioning Word docs.

• You can’t just retrieve one file at a time, you need to retrieve the entire folder or at times the entire repo.
• Word docs are binary files, so the native diffs and merges just don’t work.
• These tools are often too complicated for the business people and they end up having to use developer’s time to get help, at which point they’ll be just be able to use it but not understand it enough to use it well. Typically you will find “Spec X v1.0.doc” and “Spec X v1.1.doc” etc in the same folder of source control.

There are documentation version control systems. Use them (just not as a wiki).

DON’T : use word docs for technical designs.

The number 1 tool developers dread above all else? Microsoft Word. MSWord lets you arrange text on a page, it is NOT a technical design tool. I must admit I’ve come across zero CASE tools in my careerer – as in ones where you enter requirements, track them through a business document, technical document, the code itself and the testing process. Still I expect most of them are old school enterprise garbage tools that barely work (If you’ve used good CASE tools please let me know, I’d be extremely interested). So you know what I’ve found is the best tool for technical designs? Confluence. It’s not the obvious choice but it really works:

• You can put formatted code in it (something that is near impossible in Word).
• Developers aren’t fighting the general formatting options even when pasting doing code.
• You get built in version control.
• You can link to other technical designs or pages documenting existing functionality.
• And here’s a big one, the document actually has half a chance at being a live document. This is because a developer, just might, might, update a confluence page but they will absolutely, never, ever, update an old Word Doc unless someone forces them to. (also if they updated an old Word Doc nobody would read it anyway).

DON’T : Use restrictively-licensed plugins.

There’s a strange state of affairs in the coding world – free tools and nearly always better than tools you have to pay for. I don’t want to get into the philosophy of open source vs closed, this isn’t a moral statement I’m making, just based on my empirical evidence that the majority of free developing software I’ve used has blown away anything that has had to be paid for.
To be clear, I’m talking about the kind of paid tool that you have to install and register on each developer machine, like an Eclipse plugin or a code library. Other kinds of paid developer aids that are server/client like Confluence or JIRA but don’t actually touch your code or final product are fine, as are tools that you pay for one and then get free reign to use.
When restrictively-licensed tools get integrated into your development and then build process you’re in for trouble. Per seat licenses can make distributed development a pain, registering the product that you’re using never seems to work, if it’s required to be licensed on the machine that runs the product it’s going to screw up at some point, chances are the plugin is NOT cross platform, and the grandiose claims that the product makes never come to fruition.

DON’T : Use VMs for development.

They did suggest I do this one at my current job and I gave up on it after day 1, and then convinced another developer to do the same. He was soon coding much happier than before.
The cons of developing on a VM:

• Developing is when you need your RAM, so you’re going to have to cut a chunk of it out for your regular OS and then your VM OS.
• Chances are your VM is 32 bit XP for some reason, only 3GB or so of addressable RAM there.
• VM can rarely span on dual monitors.
• Makes interaction between your emails on your native OS to your VM OS a pain.
• Just general usability

The perceived but non existant pros:

• Ability to get a new dev started on a project purely by copying a VM.
  Wont work because : The tools have changed since the stock VM was made. If the development set up process is well documented (and it should be) then it should only take half a day to set up new. Installing everything natively also gives the new developer the benefit of running through all the tools they will have to use.
• Devs can try new software/tools and if they don’t work you can revert back to a previous copy of the VM.
  Wont work because developers wont backup their VM just to try new software. If you HAVE to try new software in a VM do it, doesn’t mean you have to use the same VM as your primary dev base.
• I really can’t even imagine any other perceived pros.

The actual pros:

• NONE!

VMs are great for test/uat/even production deployments of enterprise software. Just don’t use them for development.

DON’T : Use the old model source control systems such as CVS, SVN (or heaven forbid Microsoft Source Safe).

I must admit, I’m only a recent Mercurial convert. I previously had nothing against Mercurial or git, and I read up a bit about them but never got a chance to use them (where someone was paying anyway). After you use a tool like Mercurial one thing quickly becomes very clear, this is sooo much better than subversion and it’s ilk. Subversion itself was a fine replacement for CVS and the horrid MSS, but it’s day has come and gone.
Mercurial is:
Faster over the network
Despite the fact that every developer has a complete copy of the repository with all its history, it takes up less space than when Subversion is keeping just one version on your client computer
You don’t end up doing the horrible subversion Russian roulette of “Okay, out of these 120 files which Subversion says is different, I’m going to commit these 74. I’m pretty damn sure nobody would have changed any of these files since last night when I last updated. ARGH. Time to do an update and choose those 74 files again“.
Easier to make branches etc. It takes half a day to learn it properly but well worth it.

DON’T : Install overly invasive virus checkers

Guess what, that virus checker that monitors system files, internet traffic, new files, emails? It’s going to be more trouble for developers than any virus ever would be. Developers know computers and don’t need to be overly protected from the big bad Internet. If a developer does download and run Anna_Kournikova.jpeg.exe FIRE THEM. There’s a 99% chance that they’re a special breed of “developer” who you are paying to make everybody else less productive because they don’t know what they’re doing anyway.

DON’T : Use any configuration of hardware and software that results in long compile times required before a developer can be test his/her changes.

The number one productivity killer? Compile time. Because let’s say due to your hardware chosen by corporate strategy (which results in admins and developers getting the same low-mid range hardware) and your build process (which includes bad not-free plugins) your compile time is 4 minutes.
Now let’s say with a faster computer and an incremental build process with less overhead you could be compiling and testing your changes in 30 seconds.

So now you are effectively losing 3 minutes and 30 seconds every-time the developer needs to compile? WRONG. You are losing much more.
These are the things developers will do while waiting for a long compile time:

• Browse the web, sometimes work related, sometimes not (in their defense, the computer doesn’t have power to do much else). They often will complete reading an article and not notice that the compile finished 2 minutes ago.
• Forgot the complicated cody thing they were going to do next. 4 minutes is a long time for your brain when it was very focused on something. It now takes another 2 minutes to get back in the swing.
• Hate everybody in management for giving them a crappy computer.

In addition the above, the developer is going to try to avoid compiling and testing until absolutely necessarily which may result in the need for even more compiling and testing – because there was a step that they avoided individually compiling and testing because they hoped for the best and a subtle bug got through. Now since the developer avoided the intermediate compile they don’t know if they introduced that bug one minute ago or one hour ago.
Final result, for every extra second spent compiling, you probably actually lose four seconds of productivity.

I thought I should get back to it, and before I get back on my iPhone game, I’m going to share the simple things I’ve learned to do or avoid when it comes to making good software in a multi-person business over my many years.

The primary goal of these steps : Make the development software process fun.
The cool thing about fun development? Not only does it keep the developer motivated and more switched on, but fun development is a result of efficient development where the developer has tools and processes that help them, rather than ones they have to fight against.

My current role is on a very small but talented team so fortunately I get a lot of the good and very little of the bad. As a result I get valuable work done more quickly and I find myself happily doing overtime, even though I don’t get paid for it because it’s fun. So the reward for giving developers an efficient system? More efficient developers that put in more time. Double win.

The main way to make an efficient fun work environment? Don’t do things with good intentions that are actually quite dumb. The main areas I’ll focus on are:

• Tools
• Coding Processes
• Overall Processes from business analysis’s to developers

In short, I’m focusing on the software team AND interactions with the rest of the business to the software team.