Editorial: Shop ’til you Drop

Having had a birthday recently I am now the proud owner of some tokens for a high street ‘fashion’ store. I did try very hard to spend them – I spent something like an hour wandering round a branch of the shop in question looking at almost everything. Possibly longer. I did see quite a nice pair of black trousers, but they matched the ones I was wearing at the time and having two identical pairs seemed a bit pointless. I suspect this drew attention to me, since at least three people who worked there came up to me and asked if I wanted help. I was going to ask if they’d swap the vouchers for cash, but didn’t want to push my luck. This time consuming activity might be the best excuse I’ve got for not writing an editorial once more.

Shopping isn’t just restricted to buying, or failing to buy, clothes, shoes or even socks. Some of us may be lucky enough to choose the tool chain at work. If you use a compiled language, which compiler will you use? This, of course, may be dictated by the platform the code will eventually run on, and may not be in your control. You may need it to run on more than one platform, so might have to end up using the lowest common denominator of an unfortunate combination, such as Microsoft’s VC6 and the latest gcc. Such a combination may be deeply unpleasant, and might drive a hardware upgrade so you could avoid the older compiler, and hence more shopping. You may be writing web pages, and just tell your customers “ It doesn’t work on your browser, use a different one ” if this happens to be the case.

What tool chain would you have in place, if you had free control? Would you dictate IDEs or editors to the rest of your team, or allow a consensus to evolve or let anarchy reign and each person individually do their own thing? Would you use Excel as a bug tracking system, write your own, use an open source application, or pay for something? Or cover your monitor in post-it notes? I have been in the unfortunate position of being asked to use spreadsheets to track bugs at work a couple of times, and adding screenshots of various GUI bugs was less than perfect. Trying to use a data filter to figure out who was doing what and what was going to happen when was also a tad difficult. How do you decide which language to use? This can be based on expertise of the team, though if everyone knows FORTRAN or Cobol you are restricting potential future new hires. Going to the other extreme and constantly rewriting your software in the latest trendy language will cause a different set of problems. How many people actually know them? Can you afford the time to train new people? You may give the impression the code will continue to be rewritten each time a new language comes on the block. Perhaps you could go even further and write your own in-house language, though it may be worth considering how highly transferrable skills tend to be rated in many quarters. Of course, DSLs have a place and the ability to pick up new skills easily and deal with whatever gets thrown at you is at least as important as having experience of specific libraries, frameworks and even languages.

Do you choose to enforce coding standards? Might these include doxygen style comments, even if the parameters have no description and in general it’s only half done thereby causing 1,500 warnings hiding several import ones? Turning off these specific warnings is always possible, though it could be argued that this defeats the object of demanding the doxygen style comments in the first place. You could always go the other way and entirely ban comments. If you have coding standards do you enforce them by paying for software to help with code reviews, or do you let the troops just use pen and paper or pair programming? Perhaps you could settle for some pre-commit checks in your set up. Or use a policing system, like FxCop [ FxCop ] after the fact (i.e. a commit) and just leave any offenders to buy donuts in the case of a blunder. Either way, it involves shopping. Or, worse, talking to each other. Do you even have coding standards? You could simply say follow the Good Book [ Sutter and Alexandrescu ] or follow what Google do [ Google ]. There are many possible approaches.

Even having decided which language to use, you still need to decide which compiler or interpreter, which build tool, how you will support your applications, how you will deploy them, which platforms you will support. Some of these decisions may be out of your hands. How many places are still running Windows XP due to the perceived risk of upgrading the operating system? Some businesses have only recently moved to Windows 7, and there have been rumours that the next Visual Studio ‘14’ may not work on Windows 7, though certainly it is suggested that you only run the community technology preview on a virtual machine rather than side by side [ VS ]. Does an OS service pack force a compiler upgrade [ SO ], and if so are you comfortable changing things?

How do you decide between other supporting tools, like libraries, frameworks and so on? Do you find something open source which hasn’t had a bug report in years? This either means it is completely stable and just works, or no-one uses it, possibly with good reason. As people who code, we may tend to have a tendency to assume all software has bugs so be suspicious of something that hasn’t changed for years. Nonetheless, typing ‘ls’ at a prompt probably wouldn’t even cause a moment’s pause for thought. Perhaps bug free software is possible, but just unlikely. How do you choose continuous integration software? If you would rather avoid manipulating xml directly that will close down at least one choice (naming no names). Personal taste and previous experience will tend to have an influence in these situations. If you are selecting open source middleware, seeing the number of forks for ZMQs .Net port may be off-putting. Nuget [ Nuget ] currently finds 25 packages and github is showing 85 forks [ netmq ]. Some companies stick with tooling from one place, maybe Microsoft or Atlassian and so on. Others may stick with free software, or even insist on using open source software. These decisions can be based on previous choices, making it difficult to swap tooling. Alternatively, a perception that one has better support or quicker bug fixes than the other may hold sway. Ideally, it would be nice to be able to swap from one tool chain and set of libraries to another easily, or at least be able to upgrade compilers without several months of code changes.

Stepping back, observe that choice of language is frequently claimed to affect thought [ Language ]. For example if a number system just has 1, 2 and many this might appear to affect what you are capable of thinking about. How many colours are there in a rainbow? This varies from culture to culture too. Do choices about programming languages or even tool chain affect your programming behaviour and ultimately the code your write? If you think something like Resharper [ Resharper ] will show you code that can be improved do you just tap it out and just accept the recommendation afterwards? It can be too easy to do this, without thinking about the suggestions and their consequences. Clearly some may be good and some not. This is, of course, configurable, which requires further choices. Some setups are easier to debug than others, which can mean it becomes tempting to write more code and just step through in a debugger when it doesn’t work. If something needs deploying to an embedded system, or controls a spaceship then just running it to see what happens might not be so easy. The context in which you are experiencing your development process is shaped by your language choices, tool-chain and hardware.

More generally, your context affects your perceptions. Kant claimed that we never have direct experience of the ‘noumenal’ world, but rather experience ‘phenomena’ as conveyed by our senses [ Kant ]. This differs slightly from Plato’s cave [ Plato ], where prisoners in a cave see shadows on a wall rather than directly experience what is real, in that it does not presuppose a prototypical universe where there is one true Form for everything e.g. one true sort algorithm. Rather, for Kant what we experience is through the filter of our senses and, if you will allow me, our preconceptions. We see events happening in space and time and so may conclude one event, which always comes first, causes another. The theory of relativity may seem to upset this view somewhat, though is not incompatible with the idea that our perspective or standpoint influences what we perceive. As Nelson probably never said “ I see no ships ” [ Nelson ]. Or was that “ bugs ”, or “ shops ”? It just depends on your standpoint. It is possible to trace the history of ideas from Kant to Einstein, but this would be something of a digression.

Having got your tool chain in place, how will your development proceed? Is there ‘One, true way’ or just what currently works, given the targeted hardware, teams competency, current trend, legal requirements and so on? Does it matter if some team members write tests after they write the code, rather than before? Or perhaps having any form of tests at all seems like pure luxury. How will you deploy any software you write? If you have a continuous delivery setup then a failing test or a broken build may seem less dramatic than a continuous integration set up with a top rule: don’t check-in on a broken build [ Thoughtworks ]. Furthermore, broken tests overnight might not work for a distributed team. Do you have a prod environment, or even a testing environment, or can you just release new features straight to you customers and fix things as you go? Again, the context will matter. What works for free mobile phones applications may not be appropriate for air traffic control software.

Even having decide to buy or acquire libraries, tool chains, compilers, hardware or more generally other digital items such as music or films, will they end up cluttering up your house or work space? Many things are running on virtual machines or moving off to the cloud. There is a noticeable trend towards having e-books, rather than dead tree versions and further, people will now pay for entertainment to be streamed from the internet rather than own a hard copy. What will happen when the lights go off? Clearly this is a topic for another day. For now, let me conclude by saying I am now the proud owner of far too many socks, the reasons for which I will not bore you with, but I still have several high street store vouchers left, and probably need to buy a new chest of drawers to accommodate the new socks. Unless I find a way to stream socks. Once you attempt to shop, you have started on a slippery slope, I assure you. I will try to avoid attempting to buy anything before the next issue of Overload and hope normal service will finally be resumed by then.

References

[FxCop] http://msdn.microsoft.com/en-us/library/bb429476(v=vs.80).aspx

[Google] https://code.google.com/p/google-styleguide/

[Kant] Critique of Pure Reason , 1781

[Language] http://en.wikipedia.org/wiki/Language_and_thought

[Nelson] http://en.wikiquote.org/wiki/Talk:Horatio_Nelson

[netmq] https://github.com/zeromq/netmq

[Nuget] https://www.nuget.org/packages?q=zeromq

[Plato] The Republic (or see https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Allegory_of_the_cave.html )

[Resharper] http://www.jetbrains.com/resharper/

[SO] http://stackoverflow.com/questions/16782409/visual-studio-2012-and-program-compatibility-assistant

[Sutter and Alexandrescu] C++ Coding Standards: 101 Rules, Guidelines and Best Practises , Herb Sutter and Andrei Alexandrescu, Addison Wesley, 2004

[Thoughtworks] http://www.thoughtworks.com/continuous-integration

[VS] http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs.aspx