Tag: software development

Automatic Real Time Systems are Scary.

This is a long post. Bear with me.

We live in an increasingly automated world. And this makes me nervous.

Computers are stupid. They will only do what we tell them to. Which leads to the obvious conclusion that any given computer program is only as good as the person or people who wrote it.

I could focus on any system with this blog post. I’ll talk about the Google Self Driving Car project. It’s one I’ve been watching fairly closely, as I put more thought into how automated our world is becoming.

On the surface of it, the self driving car is something of a success story. The last monthly report shows that over the course of 1,268,108 miles in autonomous mode, no accidents were reported. Which is pretty awesome. It’s only getting better all the time, as the geniuses at Google get on the case.

I get nervous at the thought of giving up control to a system that was programmed by people. I know that in large part is down to my own arrogance – part of me is obviously of the mindset that I am better at driving a car than a piece of software programmed by a fellow human being.

Here’s where my non-arrogant issues with this come in to the equation. Let’s consider the human element in a real-time system. Things happen in real-time. Things that a piece of software may not know how to deal with – only because it’s bloody difficult to anticipate edge case scenarios, and tell the software it may happen – which requires the person or people doing the coding to anticipate this. The likelihood of such events – i.e. a meteor landing in the road, etc – is very small. But the probability is still there.

The reaction speed of a human is slower than that of a machine in a given situation, which could render this whole issue moot. But a human still beats out a machine when it comes to the ability to react. If I was a passenger in a car when the hypothetical meteor crashes into the road in front of me, I’d be hoping that the person driving the car was in full control. Not the computer of the car.

My next issue is the removal of personal and human responsibility in a machine that has often proven capable of killing in worst case scenarios. These scenarios are often down to human stupidity. The solution to this would be to make all cars self-drive. But this then also leads to what Google call in their report the ‘Hands off problem‘. You still have the issue whereby a human ability to react to the unexpected will be necessary in select cases. The ‘Hands off’ problem, and the google report, estimate that it takes between 5 and 8 seconds for a human to regain control. In real-time, this is an absolute age. Even a full second would be too long in many cases of an unexpected event.

Next, let’s talk the bug to code ratio. I only have some books and blog posts published a few years ago to go on here (after a brief google search). Dan Mayer published an interesting blog post back in 2012 which discussed bug to code ratios. It’s worth a read. In it, he quotes a book called Code Complete by Steve McConnell, which states the following:

Industry Average: “about 15 – 50 errors per 1000 lines of delivered code.”

That’s quite a scary number. Now, an error could be something fairly minor. It could be a spelling mistake in the user interface, for instance. It could also be something more serious. Here’s the thing – I suspect that this number may only have gotten larger, even in the face of better coding standards. As we work to improve an older system, for example, the system gets larger, more complex, and more interconnected with its component parts to satisfy an ever-growing demanding market that wants better features.

I’m sure that Google have very stringent code quality processes and guidelines, and as such their code to bug ratio is incredibly low. But I doubt that they can guarantee 100% clean code, without a single error. If any part of their code base meets the above quoted industry average, then I actually find that pretty frightening. And that is feasible, given that in any software development, you will have different people/teams working on different modules. In addition, how much can any published test metrics be trusted when it’s public knowledge that said test metrics can very easily be faked? All it takes is one person to either get it wrong or to abandon scruples to meet a deadline. I’m sure that the people working at Google are all fine and upstanding. Will every person who gets their hands on this kind of software be the same?

Here’s the even bigger issue. People can be clever arseholes, to put in bluntly. Cars relying too much on software have already been hacked. So even if we go with the assumption that everyone working on the software is an awesome and outstanding citizen, that’s not to say that everyone in the world is.

That aside, my conclusion is that automated systems can only work when we all give up all personal responsibility over to the system. Where does this stop? As an adult, I take pride in being responsible for my own welfare. The idea of handing any part of that responsibility over to a system – and therefore, to the people who are in control of that system – sends chills down my spine.

Don’t get me wrong – the technology is cool. It’s one of the reasons I’ve been following the news on it closely. But the ramifications of something like this being adopted worldwide is something that I feel probably hasn’t been thought about fully. Bug ratios, inability to anticipate the random, or malicious intervention aside, just who do you think should be in control of your car? You? Google? Or any governing body that takes over the software at some point in the distant future?

Advertisements

My top 5 current favourite Visual Studio 2013 extensions

I’m a fan of things that make my working life easier. Here are my current top 5 (free!) extensions for Visual Studio 2013. Bear in mind that I’m currently working mainly with C# and XAML.

  • ClipboardHistory – Keeps a history of anything that you put on your clipboard.
  • Pretty Paste – Kills extra line spaces or line numbers when pasting wodges of code around. Very handy for reusing XAML when a template won’t cut the job!
  • Productivity Power Tools 2013 – Just install it. This is awesome.
  • ResXManager – Too many languages to deal with? This helps you to manage all of them. Highly useful!
  • XamlFormatter – Formats XAML sensibly. Fixes any dodgy indentation you may have inadvertently left behind.

Low-tech tools

At work, I spend a lot of time thinking (about work related things, for the most part!).

Now, some will no doubt have a million high tech tools that suit them well. My own choices keep getting downgraded to low-tech solutions.

The two main things in my office toolbox I couldn’t do without? My A3 whiteboard, and A6 notepad.

My current task is putting together a new application. Which is great fun – but for some of the components of it, I occasionally need to brainstorm or communicate my thinking to my colleagues so we dont trip over each other so much. My A3 whiteboard comes in very handy here, as I can sit people at my desk, show them some code, show a supporting internet page, and also have the entire diagram laid out (and quickly edited) – without needing to waste paper.

My pad gets used mainly to make notes to myself. I have a couple of new pages a day, mostly. I use this to write down my own arguments for/against a particular issue before going to talk to other people about it. This is still a fairly new habit of mine, but it is paying off. I have a tendency to jump from point to point then back again if I allow myself. Having my thoguhts ordered on a notepad before entering a meeting means I can keep myself on track from point to point.

Best point about both? I can easily carry them around with me. Personally, I always feel more official when I have my notepad with me – unlike carrying around my phone, which I suspect looks like I’m handling my social life all day. It’s like having a clipboard and a lab coat. All I need to complete the look are some nerdy specs, and I can totally start giving off a perception of a brain, despite evidence to the contrary.

The Presentation – how it went

The other day, I mentioned that I was preparing for a presentation.

The aim was to – as a minimum – get people to follow the existing process. The ultimate aim was to try and get buy-in for following a full out Test Driven Development methodology (TDD).

My previous post about this generated some awesome advice – some mentioned that I should pin point a case study of where a process wasn’t followed. A former manager suggested I avoid death by power-point, and instead cover a live example of how TDD can speed up the development process. Others suggested that I follow a four point rule.

It’s just sods law that I woke up in the morning with a cracking headache and feeling sick. Awesome. I dragged myself into work, regardless – I’d put far too much thought and effort into this to call in sick on the day.

I think I managed to incorporate elements of all the advice I received. I opened up with a brief section on ‘when things go very, very wrong’, to establish that I’d already had a trial by fire for this kind of thing. I then demonstrated how time can be saved and pit falls avoided using TDD. I closed off with my suggestions that we adopt a TDD-like methodology, or at the very least follow the process we already have across the board, with no excuses. All issues were condensed down to a maximum of 4 points each, to avoid information overload. I then opened up the room for discussion.

Unfortunately, the management were unable to attend the meeting, which meant that I was really working from the ground up. It turns out that the most powerful tool in my arsenal was the fact that the product recall notice (the price of not doing this right) is still on the internet. The twitter posts are still there as well. It’s hard to argue against that.

Overall – I don’t have full buy-in of TDD yet. However, there is an agreement that the process as it currently exists will be followed more stringently. The value of unit testing was accepted as common sense, but the same old arguments reared their heads – resources and time. It was agreed that we would need more drive from a management level to get resources dedicated to setting up a proper nightly build system, and that is still the main issue with what I’m trying to get in place.

After the presentation, my manager asked me to send him and the other managers a summary of the results of the presentation, which has given me the opportunity to not only give feedback, but to also push for giving the presentation to the management.

So, the battle isn’t over yet. I haven’t been shouted down, meaning I have plenty of room to keep the argument for this going. I feel I have managed to move things forward a small step, which as the new girl in the office, I don’t think is bad going. There is still a long way to go, and I’ll no doubt be blogging about it as I continue pushing for it.

I’d like to once more give a huge thanks to all the people who gave up their time to give me advice on how to proceed with this presentation – it’s very much appreciated, and I don’t think I would have gotten a team to agree to follow the process more closely without following your advice! You’re all awesome!

WPF Snippet – Setting a Binding on a Converter Parameter Property

A somewhat techy post today.

I came across a problem at work recently – I was attempting to bind the result of a converter to the command parameter of a button. Note that below code is written as an example of what I was attempting, and isn’t actually live code anywhere. Hopefully, my fantastic naming convention will give that away.

Here’s what *didn’t* work:

<Button Command="{Binding AwesomeCommand}" CommandParameter="{Binding Converter={StaticResource ShinyToAwesomeConverter}, ConverterParameter={Binding ShinyItem}}"/>

This threw up an error:

a ‘Binding’ cannot be set on the ‘ConverterParameter’ property of type ‘Binding’

After some googling around, it turns out that the solution is to use a multibinding converter. My converter was updated to implement IMultiValueConverter, and became the following:

public class ShinyToAwesomeConverter : IMultiValueConverter
    {
        public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
        {
           if (!(values[0] is Shiny))
              throw new ArgumentException("Value should be Shiny.");

           return new Awesome(values[0] as Shiny);
        }

        public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
        {
           throw new NotImplementedException();
        }
    }

I then updated my xaml as follows:

<Button Command="{Binding AwesomeCommand}">
     <Button.CommandParameter>
          <MultiBinding Converter="{StaticResource ShinyToAwesomeConverter}">
               <Binding Path="ShinyItem"/>
          </MultiBinding>
     </Button.CommandParameter>
</Button>

So there you have it. Use a multibinding converter to bind a value to a converter parameter.

Why I love my job

I decided I wanted to be a computer programmer from a very early age. This was a decision that changed briefly when I toyed with the idea of going into psychology, but ultimately – programming and coding is where it’s always been at for me.

The main draw for me isn’t just knowing that I am in control of a machine on some level. Let’s face it – all programmers are control freaks on some level, so it goes without saying. Mainly, it’s just how quickly it all keeps changing. When I first discovered programming. it was on my Dads old ZX Spectrum. I wrote out reams and reams of code on A3 sheets of yellow paper, before patiently typing it all in and watching my code run. We were short on tapes, so this really was the best method for me at the time.

Fast forward to college, and I started to learn Visual Basic 6. University introduced me to programming concepts, such as the Waterfall Model, Object Orientated programming.

The real world introduced me to Test Driven Development, WPF and .Net. The key thing here is that much of the knowledge I have gained – even over the last 10 years – very quickly becomes obsolete. I haven’t touched Visual Basic 6 for years, and the Waterfall Model is scoffed at in favour of Agile methodologies.

That is why I will always love my work. It’s constantly changing, I am constantly learning, and that keeps everything fresh as I get to put my mind to keeping up with the curve. This all stops me getting bored with doing the same old, same old.

I can hardly wait to see what the technology will advance to in the next 10 years.

The Zone

The Zone is something that most programmers will know about. It’s that place of quiet in our head that allows us to focus all of our attention on one problem, to the exclusion of everything else. My Dad calls it ‘hyper focus’, which is also quite apt and probably more accurate.

I’m personally of two minds whether the ‘Zone’ is a good place to be or not. I can never determine how I go into it – all I know is that if I find something interesting enough, the rest of the world falls away. All that is left is my ‘item of interest’. People have been known to shout or throw things at me to get my attention when I’m in this place. A ceiling once fell in behind me while playing Sonic the Hedgehog when younger, and I never even noticed.

I’m not sure if the quality of my code gets any better while I’m in this place. Some claim that their code is the better for it. What I do know is that coming out of it, either due to someone else forcibly distracting me, or coming out of it naturally, is horrible. It feels like waking up after only 2 hours of sleep. Confusion reigns as I try to catch up on everything that may have happened while I was in the Zone. People have to repeat themselves a few times before I get what they were saying. It’s like emerging from a dark fog into a brightly lit room – you’re temporarily overloaded by all the things that you had not been noticing whilst in your own world of productivity. And then the overwhelming urge to go to the toilet, or eat/drink something. If I’ve ever gotten stuck in the Zone, I’ll often find I have been there for hours.

Some people have different methods to get into the Zone. Some need absolute quiet. Some need music. Personally, I find I just … get there. I habitually wear ear phones and listen to upbeat music whilst at work, but that’s mainly to drown out the noises of people around me so that I can concentrate when I’m not in the Zone. When I’m in the Zone, I don’t even hear the music. Or anything. Which is one of the reasons I find it kind of a scary place to be. I’ll end up in the zone through reading a book, playing a computer game, or doing work.

I actually try to avoid getting there these days. Which is actually easier said than done, given how easily I slip away to that place. I keep my usual Spotify playlist random (feel free to check it out here. Don’t judge me!). I try to make a conscious effort to take breaks every hour or so.

So, is the Zone a good or bad place to be? Honestly, my verdict is leaning more towards ‘bad’, given how awful I feel after coming out of it.