Category: 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.

Presentation Feedback

Today was a good day – I realised I must have made an impression with my presentation last Friday, as I had a few people approach me today to discuss it a bit more.

The feedback was largely positive – they found the presentation relevant, and it all made sense. I was even praised for my courage in presenting what I did, as one of the newer members of the team. The main advice I got was how to try and approach management with my points.

First and foremost – I naturally speak quickly. I speak even faster when I am either nervous, excited or passionate about something. Which, on Friday, I was all three. I struggle with slowing down my speech at the best of times. I do need to get better at it, especially since one of the guys pointed out that it made me seem nervous. He then went on to point out that if I seem nervous in front of management, I’ll probably get eaten alive. He has offered to coach me through future presentations, and even present with me – which I find to be pretty awesome, so I’ll bite his hand off for that!

One of the main pieces of advice to come through from all who approached me, however, was to try and focus more on numbers. I need to find a way to prove that what I am suggesting can save both time and money. This one will be more tricky. I may have to wait a few months until a few more projects finish, collect up some data, and attempt to crunch it into a format that can prove my point. However, not all the projects finish at the same time. The project that is ringing alarm bells for me is nearing completion – and I’m not one of the people working on it. Yet my own project, where I can prove that what I’m proposing has benefits, isn’t scheduled to complete until late next year.

So – I need data. My current sources of data may not even be comparable. My thinking cap is back on once again. Given current workloads though, I do have a bit of time to consider my approach to this, and now I have a bit more help in presenting it. All in all – I’ll take this as a win for now!

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!

Preparing for a presentation

I have stepped up to the plate to do a presentation next week at work.

Here’s the thing – we have a process. It’s all very shiny, involving the writing and running of unit tests, getting code reviews, etc. The problem is – only a select few seem to be making an effort to follow it, with oft cited reasons such as lack of time and resources when the proverbial shit hits the fan. After chatting to people, it seems that everyone agrees that the process is worth following. Just that the pressure from higher up to meet deadlines often seems to finish off any inclination to actually follow it.

I haven’t quite figured out how to go about this presentation yet. My aim is to actually get people to follow the process. I suspect that I’ll need to convince not the people in the room, but the people in charge of the people in the room. I’ve only been with this new company for a few months, and as a lowly software developer, I am lacking in political clout.

At this point, I think I’m having the meeting with the wrong people – will it be worth taking over the friday software development meeting just to have everyone agree with me, and still have no action taken? I need buy-in from the people higher up the food chain. Then again, maybe peer pressure from the ranks could help.

I’m still considering my approach, but I am looking forward to the challenge. Watch this space – I’ll no doubt be writing up another post about how it goes next week. If anyone has any suggestions on how to go about this, they would be much appreciated.

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.