Fixing bugs

Ah the joys of fixing bugs. It can be so rewarding and at the same time so frustrating. So, what we have here is 3 sets of recommendations: Reporting bugs, recreating bugs and fixing bugs.

Reporting Bugs
Anyone can say I just found a bug that crashed the software but that's pretty useless. What us devs need is a nice set of steps to recreate them. Without this it could be almost impossible to track. So, for you folks reporting bugs please try the following:

1. When you report a bug, please include a detailed description of what you were doing at the time. Logging it as 'It crashed when I clicked the mouse' doesn't help. Have, I opened form X and left-clicked on the button labelled 'Do this' and the software crashed - that helps
2. Data please. If the application has a project file, it's a good idea to include this. If you're importing data from a file, include the file. If the application uses a database, get a backup if possible. Not always necessary if the "bug" is a typo on a form or something
3. Some systems (like the one I'm working on) uses loads of generated files in the background and so a backup of the working folders really goes a long way.
4. Screenshots of the error can help.

This will help. It won't solve the problem but it'll give a solid starting point for the developer. If you can't provide information you really shouldn't expect the developer to be able to fix the bug.

Recreating the Bug
For a developer, sometimes this isn't necessary as you know right away what the cause is, especially a visual issue. I've frustrated many a developer by saying on more than one occasion "Hey, that button is off by 1 pixel, can you fix it" or "the colour is off, it should be darker/same as that other label" and they get really annoyed. Anyway, recreating the bug is good and here's a few hints as to how you might do it.

1. Get the user's data. This is really important. Sometimes it's not possible but that isn't always a problem if you can recreate the bug.
2. Start at the lowest level in the code and check the logic. If you can debug the code, step through working your way up.
3. Add traces to the code. Depending on the development environment this may or may not be easy. Visual Studio has a TRACE function which outputs to a Output window inside the IDE and you can view the results. This is really useful.
4. Dump a trace to a file. Just make sure you back the code out OR, in the case of a user not being able to provide you with data for confidentiality reasons, give them a debug build with this additional diagnostics and ask them to send the results.

This is usually straight forward enough and sometimes can take a lot of time. A couple of examples of horrible bugs follows

1. a series of small number representing the length of an item that is composed of small sections as little as 0.3 and 0.23m when summed did not add up to the actual length. The problem was caused by C++'s accuracy when dealing with numbers. 0.3 became 0.2999999997 and 0.23 became 0.22999999996. We were using double precision as well and we even created a simple command line program and assigned 0.3 to a double variable then output it and it was wrong. The cumulative error resulted in failure of the system
2. Adding tabs to a form using MFC (never a good idea, MFC not tabs). The software crashed when removing a tab that was no longer used. The creation order was the cause and the last tab had to be created first.

Fixing Bugs
There are a few useful techniques when fixing bugs. some people I know rely on catching the errors and dealing with them if an exception is thrown but that should be the last resort. Here's my recommendations here:

1. Initialise variables to something you know is invalid and check them. e.g. pointers to NULL and check they are valid.
2. Following from 1, code defensively. For example, if you open a file, check the file handle is not NULL before proceeding - don't assume it's open. Generally, check results at every step where results can go wrong, because Murphy says they will.
3. Any methods/functions you write that can generate incorrect results or errors should return error codes so higher up code can handle these errors. 2 is a recursive process.
4. IF and only IF there's no other way, try-catch is a good way to prevent a crash and at the very least fail gracefully. There's a few cases where they are absolutely necessary as a last line of defense. Sometimes a routine can execute and fail with an exception and the next time it'll be fine. If you have a system that needs to be up 100% of the time or as close to that as possible then the try-catch is a life saver...but as a last resort.

And there we have it.

Happy hunting.

Using while installing - does it work?

I love gaming. If I could get a job where I could play games it'd be like heaven but I'm restricted to gaming for fun. Some games are annoying however and this particular topic refers to the partially installed games that says they are ready to play...but are not.

First. I am an Xbox One owner. I've had an Xbox now for 9 years and why the PS3 and now PS4 may have offered better graphics, I love the Xbox experience. Now I've gotten that out of the way, let's talk about this.

Yesterday I saw Shadows Of Mordor GOTY for cheap on the Deals with Gold. So I picked it up and it was a 40gb download...a 12 hours download, optimally, on my broadband. I figured I'd get to play it as you often can with a partial download.

7 hours later. 55% done and marked as ready to play. I launched. I went to play. it was marked as unavailable 75% installed and other game types less so.

So, it was ready but not ready to play. This morning, it had stalled at 58% and so I resumed and by 61% I was finally able to start the game. I should add it was marked as ready to play at 40% downloaded ( was playing something else)

This has happened a few times. One such game, I can't even remember what it was, needed to be 100% downloaded before you could actually play it even though it was ready to launch at 10%. What is the point?? The same applies to games installed from disk.

So, yes, it looks good. I was able to run up the software. Anyone with faster broadband may have been able to play it sooner but not everyone has fibre (I can partake but the cost is too hurty)

A game is software. The initial user experience of that software was poor as a result of them mis-selling me a feature.

I should add that this works well sometimes too. For example, I played Lego Marvel Super Heroes when the game was about 25% complete and while limited to the first mission, I actually was able to play the game...note the operative word Play, not launch.

Game companies out there. If it's not ready/downloaded enough to play then don't let the user launch the game until it is. It's called managing expectations - I was really gutted last night.

Good game however...so far.

Help!

Not everyone likes to ask for help but sometimes someone knows the answer to something you don't and trying to figure something out can take time.

I am of the school of thought that it doesn't hurt to ask and can often save a great amount of effort. Some people don't like that.

A colleague of mine, a nice chap too, when he joined the company was working on software with me and he was terrible for this. I always said "give it an hour and if you've not figured it out, give me a shout and we'll take a look" or something to that effect. I think an hour is good.

Of course, there is the manager point of view that if you're asking someone for advice then they aren't doing their job and neither are you.

A counter argument is that if you put someone in charge of a project then they must actually be fully intimate with the details of a project. It therefore stands to reason that they may know the answer to something that saves you time and therefore makes them look better.

"You're distracting them from their job"

I do like figuring things out but I'm impatient. I like to get things done but if I hit a brick wall then it's not getting done and I want to move things along.

The answer is to think about the questions and write them down and that way they are focused. Email them if you like (na, that's no fun) but if they are written down then you have thought exactly for what you need.

Which is right? I ask. Doesn't mean it is right.

Imagination vs Reality

When I left school at the ripe old age of 16 to do an HND in Computer Studies we were told at the start of the course that I would be almost guaranteed a job after graduating. The reality was people wanted a BSc or similar to hire people unless you wanted to be stuck in tech support. This is one of the Imagination vs Reality situations I've come across.

I did go and do 4 years at a University and still graduated age 22 with my good ole degree...and I ended up doing tech support. I can't complain. I met my wife through that job but I imagined I would be coding up a storm.

I imagined I still would be coding for fun at home, something I did until maybe I was 26 or so and then I realised I needed to get a bit of a life.

The biggest shock however is that office life is not quite what you see in the likes of IT Crowd, The Office or anything like that and while you see videos about people running around the office dressed in pac-man suits chasing someone else dressed as a ghost, the truth is seriously disappointing.

It's not without its laughs. My first programming job was mental. We would go out frequently on a Friday and get seriously happy from 5pm until rolling in home at 3am.

Then there was the minor pranks. One of my bosses used to get upset if the paper cupboard under the fax was left open so every time he left the room we slid the door open a few cm. He would walk in, see it open and close it to much mirth of myself and another colleague. We even took it to the next level by using packing take so when you closed one side it pulled the other door open.

We would race mini remote control cars in the corrider.

The directors would even occasionally partake in a network game of C&C which was always a laugh and we always had to cut it short - an hour was not enough time and we had work to do after all.

The time old classic of removing the mouse ball doesn't even apply any more in the days of optical mouse - the replacement being take a small post-it note and cut a square, stick it over the sensor.

The confusion, oh the confusion.

Telling users they were getting kicked off the mail/conference system because there was a transient network glitch when in reality you were clicking log user off on the admin screen just for shits and giggles.


The reality is this is about as far as it goes and often not as far. No stapler in jelly, no "rowing" down the aisles in the open plan offices. The office I'm in is more akin to a library with a "be quiet" sign and even then the local library where we take the kids to at the weekend is a regular riot compared to the office.

If you have an office job where pranks are commonplace, please share them.

If you yearn for this kind of stuff then you can do no worse than read the wonderful tales written here: http://bofh.ntk.net/BOFH/index.php

C++ vs C#

Background
My career is varied and quite long. I started out age 11 on TI BASIC and then ZX BASIC, writing a game at age 14. By 1990 I was using C and 68000 assembler quite freely and in 1993 I did a text editor in MC68000 on an Atari ST, some 130,000 lines of code in under 3 months for a university project.

My use of C++ came about around 1995 when I started working for a college who had a contract to write a piece of educational software for Windows 3.1 just before Windows 95 was released. I'd been dabbling at home and I actually got a very cheap license of Borland C++ 5.

In 2001 when there was a beta of the SDK I dabbled with C# and also at the time I was heavily involved in ASP development. In late 2003 the company I worked for got a contract for a small app and we did it in C#/ASP.NET and that was my first real .NET application - I never looked back.

About 3-4 years ago I slowly moved back to C++ in the form of MFC while working on projects in C#. We use Visual Studio 2010 currently and have done for around 3 years (VS6 previous!!) and looking to move to VS2015 soon.

You could say I have a bit of experience in both languages. What language would I recommend?

There is actually no clear answer. For basic simple applications I would say it probably doesn't matter too much. For larger projects with many users there are issues. Below is a list of what I deem key points for both languages.

C++
C++ is a nice language with real power. In VS2010 the insight is not great and if you happen to want to use a native/framework hybrid then you're in for a world of hurt - I know newer versions address this.

• C++ is fantastic for 3D work (DirectX) in windows apps.
• It's also fast so if performance is an issue then it's great.
• The language is established and there's a lot of cross-platform code out there that just works.

The downside?

• UI-wise it's a very painful experience. MFC C++ in particular uses a .rc file for the form design, menus, images and the likes and when you're working on multi-user projects the merging of resources is a nightmare - often so that it can go totally wrong. You have to co-ordinate commits of  resources with the team.
• Then there's another issue which is crazy IMO. Numerical accuracy. Doubles are supposed to be accurate to 14SD or there abouts and yet assigning 0.3 doesn't give you 0.3, it gives you 0.2999999999999997. We discovered this recently.
•  Finally, Because of heavy use of pointers the learning curve is big and memory leaks like to happen - studio does report them but in a vomitous form.

C#
C# is similar enough in syntax to C++ to be easy to learn and also the fact the languages (libraries excluded) are simple makes the journey quick to get up and going.

• C# as you are probably aware supports WPF and Forms development as well as ASP.NET. This has the advantage over C++ in that the forms are handled individually so greatly reduced merge conflicts. 
• Numerical accuracy seems better so the C++ number issue doesn't occur.
• There are massive libraries and if a library doesn't do something, there's a lot of code out there too and third party control libraries.
• Code is easily shared between apps and even to C++ via COM - it can be done both ways.
• Loads of plug-ins to help with authoring of code
• Visual Studio and C# together work beautifully.
• LINQ - it's brilliant and while VB.NET supports it partially, C++ supports it fully and it's a beautiful thing. 
• Generally C# applications look nicer because they can.
• If you need to work with databases, C# and .NET is fantastic and you have so many choices as to how you do it. It's not impossible with C++, it's just it's so easy with C#.

There are downsides too.

• WPF can be painful, if awkward. Sometimes things just don't work the way you want them to.
• It's not as fast as C++ but it's a trade-off between performance and speed of development.

Summary
Looking at the 2 lists, it would seem clear that C# is actually the best of the two but it really depends on what you are doing. Does your application need CPU Intensive calculations to be performed quickly??? This may actually be the key point. Also, does it need heavy 3D graphics* or are they basic enough? Do you need to share code between web and windows apps or possibly even other applications like MS Excel? Do you need to use a relational database?

Sharing is easier for C# or .NET in general and doing things are generally easier. C++ excels at speed and 3D and you can use pointers to squeeze every ounce of that performance out of your system when working with huge amounts of data.

What would I choose? C# pretty much most of the time. It's just easier to work with. C++ for anything that needs a 3D display without question.


* 3D is supported in the likes of WPF but as we experimented, we saw its limitations compared to using DirectX - it works, it's fast and it just wins. What a team did was write the 3D parts of the app in C++ and embeded them on a WPF form and it works brilliantly.

Rules and laws

Rules are good....sometimes. I'm a great believer in the flexibility of doing things...when it comes to layout there's a lot of time wasted on certain things like where curly braces should be and whether or not they should even be...

Let's take this little C++ example:

if ( a > b )
{
    a++;
}
b = b - a;

and now this example:

if ( a > b )

    a++;
b = b - a;

These are the same...until they are not. here's the same with code commented out.
if ( a > b )
{
//    a++;
}
b = b - a;

and now this example:

if ( a > b )

//    a++;
b = b - a;


These now do totally different things. I came across code a while back that was exactly like this and it was hard to tell what should have happened after the IF statement. I therefore always write the code the first way using the braces. A more senior (in title only, I have 10 years more experience) colleague of mine then went through my code and stripped them out because he didn't like them.

Some rules are good like curlys always. If you need speed then omit them as rules are made to be broken. Comments are free.

This brings me to the laws. I have 3 laws. They are straight forward and they are definitely not original in anyway and collectively I call them Brian's Laws...a bit like Asimov's laws of robotics...not really, I'm no Asimov.

Law 1. If it ain't broke, don't fix it.
Fairly self explanitory. Leave it alone unless it genuinely is broken. However....

Law 2. Simple is good.
There's often loads of ways to do stuff and the simplest often means easier to maintain and less likely to need fixing in future. Now, simple is not always possible but simpler can usually be achieved.

Law 3. Just because you can, doesn't mean you should
This needs explaining a little. Imagine some code that is really complicated and, with a bit of effort, can be simplified (Law 2) but it isn't broken (Law 1). Law 3 helps here. Just because you can simplify the code, it does not mean you should do it.  It doesn't have to be Law 1 and 2 in conflict. e.g. Just because you can have another coffee (after having 3) doesn't mean you should

These laws are a great guide to not just programming.

There's a secret law 4 I often keep secret as it's not quite as absolute as the other 3 and I work with a bunch of folks who fall into law 4 and it really holds true for a lot of them.

Law 4. Do not let non-software grads code
This is tricky. There are a few good non-s/w grads out there who actually are great at coding. However, I've met more than not who fall into law 4. A lot of folks have a post-grad in S/W development but I would say this - you cannot learn in a year what normally takes 4. And Java...really... I think learned (or dabbled) around 15 different languages through college and what that taught me was diversity.

Keep law 4 to yourself but always keep it in mind.

Beauty

What is beauty?

It's sort of subjective as to what is beautiful. To me, my wife and children are beautiful. Sunny days on amazing beaches, the Burren in co. Clare and tree tunnels (when trees shade a road and you drive through surrounded by the green folliage) are all beautiful. These would be things most people can agree to being beautiful.

Other things that are beautiful as far as I'm concerned will probably not be so easy to understand.

1. The Xbox One
To me, this is from years of evolution of the hardware to produce an affordable piece of kit that can sit fairly unobtrusively in your front room enabling games to be played and entertainment to be had. Skyping family from the TV is cool and the new-found integration with Windows 10 is great. You can't fault it really.


2. Amazing innovation and ambition
This is more a generalisation but something like space-ship one and two fall into this category. They are beautiful not only in their innovation but the sleek lines and what they are trying to achieve. Other things that fall into this are the Raspberry PI which is incredible for its size and what they are trying to achieve with it and everything Elon Musk is doing - the Telsas, SpaceX and his super-fast trains.

3. The perfect piece of code.
A task that is complex and suddenly you discover something so simple that just works and is so simple it can't go wrong. This leads to beautiful software which there is plenty of. I often get excited over little bits of software I've written that do cool things. Windows 8 tried to be a thing of beauty and it nearly did this. The problem is people weren't ready for windows tablets and Windows 8 isn't ideal on desktops. Windows 8.1 improved this but the power/speed of Windows 8 was lost. Windows 10 however has addressed these concerns and, IMO, they have created something beautiful.

My Linx 1010 arrived and it's a thing of beauty - it's not a surface which is a stunningly beautiful piece of hardware and software, but,  a full windows OS tablet for 1/2 the price of an iPad with USB ports and SD slot - you can't go wrong.

Beauty doesn't necessarily have to be things you see but they can be ideas too. I like things :D

Coders and Gaming

I feel today that coders fall into 2 categories: those that game and those that don't. I think it's possibly the culture here.

I discovered computers were real when I was about 11 and up to that point I thought they were make believe in the likes of Star Trek and the movies. That's kind of strange considering I had an uncle who brought around an Atari VCS to our house that he borrowed from his girlfriend's sister every week back when I was in primary school. They came every Wednesday and the kids (me) would play games for 1/2 hour before bedtime. About 2 years later we got our own one but I never did think about where the games came from or how they were created.

In 1984 I got my first computer (shared by myself and my brother) and we had a single game - Moon Patrol. From then until I graduated from university I spent a lot of money on games and even more time playing them. I wrote a lot of code for fun too and published shareware.

I gamed from a young age and coded from a young age on that computer and all subsequent computers as well.

My career is a software engineer hit 20 years on the 30th August where my first job was support with some software develoment for good measure. Where I work now we currently have about 25 software developers but about 23 of those aren't what I would call software developers. They are engineers with Post-grad MSc in software something or other. They don't game. I think there's 1 or 2 but compare that with the previous company I worked for - 11 developers and at least have enjoyed gaming to excess. All of those guys were pure software graduates.

I love games. I'm actually not great at them but I love them. My son, 5,  loves them too but he gets once a week for an hour at the weekend for being good. I don't want to deprive him of the experience but I want him to understand limitations. Not like the 18 hours I used to play at a time instead of being in the pub with my classmates at the weekend.

Notes: My Mum and Aunt used to play games every Friday too - my family is big on gaming. They played Frostbite on the VCS and when we moved to the ZX Spectrum it was Sabre Wulf (see Rare Replay) among others. It's no wonder I played a lot of games.

Taking the plunge

Have you ever been burned when you take the plunge on new tech.

I have to say it wouldn't be the first for me. Years ago I bought an Atari Jaguar and it was expensive. The CD drive was equally expensive and cool and unfortunately both were massive failures.

I got a budget android tablet which goes maybe for 90 minutes before it switches off...'nuf said.

We got a laptop which cost us 400 Euro a few years back. The battery was poor (~1 hour)  and the video card sucked - it was fast with W8 (25 seconds to desktop) but the video card wasn't supported, hence sucked.

Nearly got burned with a Samsung galaxy S5 - didn't work for some reason with my sim card and I believe it was faulty. person I got it from was nice and refunded me.

Yesterday, after much angst my wife got me a Linx 1010. I've been wary but I've heard great things of the previous models. The 1010 being the latest model is something I wanted because I want a tablet and the surface being way out of my league price-wise, the linx being an affordable little beastie. The lure for me was the 2 full USB ports - I have a nice 2TB hard drive to use with it.

What do I want it for. Travelling, minecraft and  the odd bit of word processing and printing. Oh, and streaming from the Xbox One. I could stream sky from the xbox one via the linx to the TV we have upstairs using smartglass on my iPhone as a remote control... :D

My wife has an iPad and she loves it but I want PC apps - I want VLC, I want expandable storage and I want full word and I have 2010 lying waiting to be installed. I want to be able to put movies on it easily for travelling.

I hope this is not a whim.

Keeping on top of things

Well, I had every intention of keeping this up but it's crazy. 2 kids and a lego and games addiction makes it difficult.

It's not the only thing. I'm predominantly a C# Developer although more recently I've been subjected to C++ and MFC. It's not awful but it's slow and at times painful. Going back to C# and web development I suddenly discover it's changed...I mean, we're talking not a little bit but totally changed.

The whole using ASP.NET controls seems to be replaced a lot with JQuery and other frameworks. It's not a million miles away with some techniques I used to use, you know, hidden iframes and sending javascript arrays back from the server with code to update the form...now you ask directly in script and asynchronously update.

Then there's the likes of MVC which I looked at and since has been upgraded 3 times I think.

Why is this like kids and lego and games?

Well, the kids are growing up and my daughter actually grew 5 cm in 8 weeks. (we mark a door frame)

LEGO is so hard as there's new sets out every month. Just when you complete one set of CMFs another is launched. I wanted all the superhero sets but when they are wanting 500 euro to get a wave of sets, nope....

Games is the hardest. I sold my Xbox 360 to get the One last year and I said to myself, finish a game then get a new one....ha! yeah...right.

Also I was writing a Pac-Man Clone and was 80% complete using XNA and boom....bye bye XNA...seriously.

It's impossible keep on top of this as everything changes so quickly so my advice here is this:

Learn what you need to know now and keep an eye on the rest...anything else is a waste of effort.