No Comment

There seems to be a push towards not commenting code, with the general argument being that if your code needs commenting, it is too complex. I kind of agree with the sentiment here, code that is tough to comprehend is bad, but I think this is an oversimplification.

In my experience, at the point at which we are writing the code, we are terrible judges about what is too complex. Things we think we will be obvious to anyone [including the new person, straight out of uni] reading through the code turn out not to be obvious, not even to us – six months later when we are trying to track down the cause of a bug in said code.

There is a secondary argument, that comments are not always accurate, because…

The author of the comments has described the intended functionality of the code, but this differs from what it actually does.
The comments may not accurately describe what the code *is* doing, but they might neatly explain what the developer *intended* for it to do and that could be very useful information when you are searching for that oh so elusive bug.

The comments have not been maintained in line with the code and are now stale.
People don’t always do the right thing because reasons. Expect the bullshit but never accept it. Do code reviews; include the comments in the review.

If you find yourself writing comments like “Increment counter”, you should stop. If you have contrived to produce some horribly obfuscated, overly templated, pointlessly typedef’d hell that requires a comment the length of War and Peace to justify, you should be stopped. But if all you want to do is try and give a helping hand to the next person, get to it. :)

I am still learning. I hope to carry on learning forever. I might well be wrong about all or some of these things. I might change my mind on them in the light of more experience, or different arguments. I am totally okay with this.

The Uncertainty Principle

A new code review system is being introduced at work which will see new/changed code formally peer reviewed before being accepted to the code base.

Sounds great!

It is, from the point of view of streamlining our development process without compromising on quality.

I sense a but?

But… the whole thing has me burning through spoons fast.

How so?

I’m worried because the process will force the two kinds of interaction that I find most troublesome when working with NTs:

1. Following a set of rules.
2. Providing fact based feedback.

Rules and facts; no offense, but isn’t that what you guys live for?

Ha, no offense taken and without speaking for all autistic people, it does seem to be generally true that we like rules and facts.

So what’s the problem then?

Well, following rules around NTs is hard because they don’t follow them. Or at least they often treat them as optional. I can’t do that. I’ve asked the Rule Makers and been given clear guidance that I should always follow the rules. If I break the rules, I am disobeying an instruction – clearly wrong. If I follow the rules, people get frustrated with me – clearly undesirable. So I just have to wait for the conflict.

And providing feedback, what’s the problem with that?

Essentially, it is the uncertainty of the interaction – I have no scripts that I can use to guide me.

Practice makes perfect, I’m sure you will pick it up.

I doubt it. I develop scripts using a trial and error approach, but this requires predictable results and in terms of providing critical feedback, I can find no pattern in the responses and reactions I have observed. I have spent the past few weeks trying to prepare in readiness for the change, informally reviewing the checkins and working on providing feedback without upsetting or antagonising people. This can’t hurt, but I know it’s not going to help.

What are you going to do?

I’m going to make sure that I use the review process tool to the best of my ability to try and ensure the quality of our code is as high as possible. I’m never going to compromise there. I’m going to try my best to spot patterns in behaviour and change course before DEFCON-1 is reached. And if an NT locks on to me and malfunctions ED-209 style, well, I just hope someone is able to pull it’s plug before my skin turns green.

Post tune: Ludacris, Beast Mode.

The A-Team

People tend to treat development processes like religions. There are lots of extremists.

Everywhere I have worked has taken a somewhat agile approach to delivering succesful software deployments, without subscribing to any single agile approach in its entirety.

I have found that one thing, in numerous forms, is key to the success of agile: communication.

It is important that the development team is close knit and pulling in the same direction. Regular stand up meetings help to keep everyone on track and provide the most notice of blockers and hence the most chance of avoiding/mitigating them.

It is important that customers (anyone who consumes the output of the process) have opportunities to provide input, feedback and guidance.

It is important that the documentation burden is minimal and that all documentation is clear and concise.

Communication requires dialogue. If only one side is investing in the process then it is unlikely that the information exchange will be succesful. Further more it is likely that the input will not be received in a timely manner. I know, I know, one of the principles of agile is being open to changing requirements at a late stage of development. The key word in that sentence is late, there will always be a time when it is too late. Attempting to change requirements within a sprint, whilst expecting the overall duration of the sprint to remain the same, requires a certain level of delusion.

One of the distinctions between agile and other methodologies is the emphasis on people rather than processes. The streamlined processes require discipline and trustworthy and motivated participants. Agile demands the ability of the participants to sustain a high pace whilst maintaining their focus on technical excellence. As such, holding people responsible for their actions (or inaction) is not a bad thing. After all, it is only a mistake the second time it happens, the first time it is an opportunity to learn.

To me there is nothing ground breaking here, so why do people insist on making it so complicated? I suspect it is because agile quickly highlights weaknesses. A wise man once said “A players like to work with A players”.

The customer is sometimes a douche nozzle

The changes in recent years in the way in which software is distributed and sold have heralded some great things. People have genuinely never had it so good. It is easier than ever before for people to source legal copies of well maintained apps for their mobile devices and/or computers.

Software doesn’t grow on trees though. It takes time to develop; to design, code, test, release and market. It takes more time and effort to maintain; fixing bugs, adding new features.

The point of this post is to highlight the bullshit sense of entitlement that seems to have developed alongside the app stores.

You paid ‘x’ amount a year ago for the app and you don’t think the changes in the new version justify the price? Cool beans, don’t buy it. Stick with the version you have. Even when an app is declared feature complete, it is rarely pulled off the shelves. Even if the developers move on to the next major version, they will normally still offer bug fixes for the previous versions. Even if they don’t, the software doesn’t suddenly stop working when a new version comes out.

And if you ever find yourself saying “All they’ve changed is the way it looks!?”, please slap yourself. In the face. With a shovel.

Not very Appley

I wrote this during the week, but I haven’t been able to post it until now.

I signed up for an iOS developer account with Apple last week. The sign up process was every bit as slick as you would expect from Apple, although I was advised that activation could take up to 24 hours, which seemed reasonable enough – I know that there are certain checks that have to be performed to protect Apple’s customers against fraudulent developers/apps.

A few hours later I got an email telling me I could go ahead and activate. I followed the instructions but was unable to complete the activation.

The next day I received an email from Apple saying there were inconsistencies in the data I had provided and requesting that I upload a copy of my “government issued photo ID”. No details of exactly what was inconsistent were provided. I double checked all of the data I had provided, I could not spot any errors.

I contacted Apple through the developer portal, expressing my confusion and seeking some sort of clarification. The Contact Us page says that they will return emails within one business day, but I waited for two business days to pass and then contacted them again as I had not heard anything. That was three days ago. Today I finally received an email response, except instead of being helpful it reiterated exactly the same message, there were inconsistencies in the data I had provided, but no details on what they were.

I decided to phone Apple.

My call was answered quite quickly and the guy on the other end of the phone took my details and tried to find out what was wrong. He explained that I had provided two different names during the sign up. I knew this was not right and so waited for him to expand. It seems that in one place I had listed my name as Mr F Oobar and in another I had listed it as simply F Oobar. I could not believe that this was the cause of the issue. One of the fields I had completed during the sign up process asked for my name as it appears on my card, the other asked simply for my name. Whilst I could understand how this could cause a computer to flag the play, I thought that a human being would instantly be able to diagnose the problem and dismiss it as unimportant. I asked the guy from Apple if he sort the issue out now that he understood and allow my enrollment to complete. Nope. Still needed to see my passport or drivers licence.

I was pretty annoyed at this point and said that if the guy was unable to complete my enrollment that he should go ahead and cancel it and refund my money. He didn’t argue and stated that I would receive an email later on explaining the details of the refund. I considered the matter closed.

When the email arrived it stated that they had processed the refund I had requested as “an exception to our policy”. Really? Because I thought that the Distance Selling Regulations made guaranteed my right to cancel when the contract was never concluded, I was never able to access the service and I had first attempted to contact them well within 7 days?

Seriously Apple. This is not what I expect from you and it really is not good enough. I am shocked that this is how you treat developers looking to contribute to your platform. :(

Organisation Theory

Some of you may know already, but I am a Software Developer by day. Part of my role makes me specifically responsible for the quality of the software, although I would argue the entire team shares this responsibility. We have a bunch of QA procedures that are designed to ensure the quality of the software too. The idea is that everyone should follow the procedures and that this should guide us towards producing high quality software. Equally as important although not the focus of this post, the description of these processes allows us to explain clearly to other people what it is that we do to maintain our high standards.

So what happens when people don’t follow the procedures? Well, essentially things start to go wrong. Things get missed. Problems creep in. The quality drops.

This maps on to my everyday life.

I need to be organised. I can’t get focused if there is loads of stuff on my desktop, physical or virtual. I position my stuff on my desk in the same place every day. I guess I can use my muscle memory and it becomes one less thing to think about. I hate having bits of paper hanging around; I take notes in my logbook, but that paper is organised by the metal spiral running along one edge. The first place I worked when I left university was paperless, I loved that and I still try to maintain it today.

All too often the rules of life are unwritten and have to be learned through trial and error. Even then, rules that I have taken as learned I see broken by others.

I have procedures and routines for doing just about everything. I need to stick to these in order to make sure I don’t make mistakes and also to make sure I am in control of what is going on.

It’s not just about being efficient though. I really am unable to tackle something if I am surrounded by chaos. Yes, to me, having stuff all over my desk is chaos. I guess this is where the distinction between neurotypical and autistic falls?

Doing things my way may seem regimented and inflexible, but the flip side is that I know exactly what is going on. I can see things in the finest detail. I know instantly when something is wrong just by the disturbance, it’s a bit like a spider sensing the tiniest vibration on it’s web. If you take away my procedures and routines then you are taking away my spider senses. Not only do I have to deal with the feeling of change and uncertainty but I now have to try and do things in a way which is totally foreign to me. This all feels horrible for me and is extremely overwhelming and so I am fiercely protective of my routine and of the organisation of my world.

Organisation Theory: on one side of the earth an aspie does something using a well worn routine and this results in good things happening.

This Dev’s Life

I love watching something slowly coming together over a period of time. Each new line of code, each new function, little building blocks. Then when it’s finished you can stand back and say “I helped do that!” and be proud. I don’t want my name on it if it doesn’t represent the best I could do.

I like searching the code to track down and eliminate an illusive bug, or trying to work out how to make something work, trying to determine the cleanest design. Somehow I feel that my effort makes it more valuable. Like the difference between a hand built Aston Martin panel and a stamped out panel from some other car company.

I like taking something that already works and making it better. Completely unchanged on the outside, infinitely better on the inside.

I like working with people as passionate as I am about doing a good job, who get as excited as me when they see something work.

Woo woo woo… you know it!

One of the things I’ve been working on recently is an in app editor for the OGRE based 3D GUI that forms the front end of one of our main products. One of the features that I added was the ability to switch between scenes with the click of a button. I was able to get this working on Windows with little difficulty, but on Linux I constantly got the same assert.

ogre/RenderSystems/GL/src/OgreGLSupport.cpp:56: virtual void Ogre::GLSupport::initialiseExtensions(): Assertion `pcVer && "Problems getting GL version string using glGetString"' failed.

I have revisited this problem several times in recent months and each time my investigation faltered at the same point. The first time a scene was loaded, everything was fine, the second time a scene was loaded OGRE failed to initialize the OpenGL Context. Something wasn’t being released correctly when the first scene was shutdown. I tried everything. With OGRE it should really be as simple as calling shutdown() on the root node and then deleting the root node using OGRE_DELETE, but it just wouldn’t work.

This past Friday I finally got it working though. The following code snippet is from the second time that OGRE tried to initialize the OpenGL render system. The dimensions of the target render window are wrong. For whatever reason, Qt was not able to finish initializing the container widget before I was grabbing the X11 info and passing this onto the OGRE initialization code. A simple decouple using a 1ms timer sorted the issue.

******************************
*** Starting GLX Subsystem ***
******************************
GLRenderSystem::_createRenderWindow "SomeWidget", 1059x0 windowed  miscParams: parentWindowHandle=135727904:0:56624998
GLXWindow::create used FBConfigID = 117

I’m not going to lie, I fist bumped like The Long Island Iced Z when I saw that model reload! :D

echo “Oh shit!”

I spent the back end of last week sorting out the RPM creation process for some projects I’m working on. We tend to use CheckInstall to generate the first cut spec files and then manually update them. I had done all of the hard work; I had the spec files down for the various RPMs and I had bash scripts set up to generate them. I asked a colleague if he knew the switch to pass to CheckInstall to have it select RPM automatically, just to make the process completely fire and forget. He didn’t know off the top of his head, but said that he would look it up. I Ctrl+C’d the script and watched as CheckInstall cheerfully entered it’s clean up routine. Did I not mention that CheckInstall has a helpful clean up routine built in? It tidies up (deletes) everything in the $BuildRoot directory. Unfortunately CheckInstall hadn’t got far enough into it’s execution to reinitialise that variable, which I actually also use in my own scripts. It points to the root of my workspace. CheckInstall very cheerfully nuked the whole thing. You have been warned.

Post tune: Gold Cobra, Gold Cobra, Limp Bizkit.

I am a mutant

I am a mutant. I was bitten by a radioactive spider during a school trip and… I’m lying. I don’t have any superpowers, I’m just colour blind. I’m not full on grey scale colour blind, I am Tritanomalous and Deuteranomalous, or more simply I am red/green and blue/green colour blind. Being colour blind has a very negligible effect on my life, 99% of the time I don’t notice and it doesn’t matter when I confuse colours. Notable exceptions include the “green” light on new style temporary traffic lights which I perceive as blue, the coloured bands on resistors (again, apologies to the electronics lab tech during my time at uni) and my trainers with the “blue” strap on them – my Mum requested this one was added in after I had her spend an afternoon looking for trainers with a green strap.

Anyway, enough about me, this post is for you. Okay, a little bit more about me first… I am a software/web developer and because I am colour blind I am aware of certain issues/limitations which other folk will often completely fail to consider when designing User Interfaces.

Colour Choice: Lets start with the biggest potential mistake: colour choice, you need to consider where colours are in the spectrum. I found this website which allows you to generate and compare colour palettes, but it has the added bonus of allowing you to see how your colour scheme looks to people with the various flavours of colour blindness. What looks complementary to you may look incredibly odd, or worse still completely identical, to me.

Colour Mass: But it’s not just about colour swatches, you need to consider the amount of colour that is used because colour mass also effects perception. A thin line of a certain colour may actually appear as black to someone who is colour blind, whereas a slightly thicker line will be able to be perceived without problem. In exactly the same way, colours can get lost in the “noise” of other colours if too many are grouped together.

Texture: Another important point to consider is that the texture of an item can really effect how a colour blind person perceives it. A printed design mock up can look completely different to the design as viewed on a screen, and different again when viewed on a different screen. Textures and materials do effect colour perception.

Consider this post on “Better car brake lights” by Mark Cossey. Hopefully you can now see that using escalating colours to indicate how severely the car is decelerating would be dangerous, whereas flashing lights would be without problem to the majority of colour blind people. This is why in general, I don’t think that you should ever use colour alone to present information to users, an additional albeit slight change in appearance will make your design much more accessible to both colour blind and regular sighted users.

Armed with the information in this post, you should be able to appreciate the absolute best thing about being colour blind: some forms of camouflage are completely ineffective when used against colour blind people. If only this applied to Call of Duty!