Darren Steadman

Earlier in the year I posted about helpful software errors, this article builds on this and offers a discussion into making it as easy as possible for users to submit relevant issues with software but at the same time making the information as useful as possible to the developer.

Let’s outline some of the things that could be done.

Gather anonymous statistics

There are already lots of applications out there that gather anonymous statistics about their usage. This can be very useful for finding out simple information like how often a feature is used and how people get to that feature (so many apps still have 100 ways of doing the same thing). This can be useful when devising test plans or when deciding if features should be dropped or if features should have more time spent on them.

In application issue submission

The first time I saw this happen was in one of the Windows 7 betas, they added feedback menus to all windows so that users could submit bug reports or feature requests from a relevant place. I think it would be useful for applications to have a feedback button on all of its major features so users can quickly file bugs and feature requests that can automatically be categorised based on UI elements. Combine this with the anonymous data gathering and it gives you an idea of priorities when fixing bugs or implementing new features. It could even be possible for users to view other users submitted issues for a feature allowing them to up vote the problem or even provide additional feedback to the issue. It would also be possible to give feedback to the user on the status of their issue via the application itself. This kind of system brings the support system right into the application itself rather than forcing people to find the application support somewhere else, it also gives a sense of good customer support to the user as they feel they have visibility as to if their issue is being addressed.

Application container

I know this kind of thing can in theory be done in .NET and I assume depending on security restrictions it could probably be done in other VM based languages. You could run your application in a container that recorded the state of the application, so basically stack traces and memory contents. This data could then be played back later while the application was attached to a debugger to see what the user did to create the issue and what state their application was in. Microsoft already provide such a container but licensing means it can’t be used in a shipping product. A less full blown equivalent could be a way of recording what buttons were pressed and when as well as values entered via the keyboard this would then allow you to recreate the application state rather than record it directly. There are obvious security and privacy concerns related to this kind of recording but it could be possible to implement it in such a way that the user could explicitly turn the feature on to help diagnose a problem.

Well that’s a short list of potential starting points to allow better more accurate issue capture in applications.

A friend recently posted about using a chess timer in software development. This is my argument against the conceptual need for it.

The main reason stated for the timer is to indicate when development has had to stop on a project due to needing external events to occur, those events could range from a decision being required to something being signed off to requiring a piece of information.

It is stated by the writer to his own admission that he is bad at estimating development timescales and I believe this is the problem here and why the timer is required.

If you can’t estimate your own timescales then how do you organise your workflow and the workflow of people around you? Time wasted on waiting for decisions can be massively reduced by knowing your timescales because if you know your timescales you understand the extent of the work you are doing and the key bottleneck points, if you understand them then you can make people aware of decisions that need to be made in advance to when you need them reducing any time waiting for things you require to continue.

This obviously won’t eradicate all wasted time, there will always be situations in the development cycle where unforeseen problems will occur but even these can be massively reduced with correct specification of the work to be done and by keeping a tight iterative process where problems from the previous iteration can be addressed while another iteration is being implemented.

In conclusion I think the timer isn’t required if time is spent at the specification phase to identify as many as the problem areas as possible. Development should then be done in tight focused iterations and most importantly good time estimates are given so that all people in the development are aware of when information is required.

As I mentioned a couple posts back I am attempting to make my first iOS game before I’m 30. So far things are going pretty well, I’m nearly reaching a point where the first phase of game code is complete. Once this is done I will effectively have a product that is functionality what I want.

Next I’ve got to move onto giving the game a consistant look and feel and start developing the actual graphics, at the moment I’m using place holds for everything and it intentionally looks awful. Once the first lot of real graphics are complete I’m hoping that will kick of a slowly reducing cycle of tweaking code and tweaking look and feel until I’m eventually happy with everything and am ready to release the game.

The issue I have now is if I will actually be able to get this all done by my 30th and at the moment I think it will be close but will probably fall just past my birthday, what with climbing, work and my second child arriving soon my free time is slowly shrinking but I am determined that this game will get finished as close to my 30th as possible.

Once I get the first lot of real graphics up and running I’ll start posting some screen shots of how things are going and maybe even some video.

I’ve been seeing a lot of arguments flying around blogs and twitter just lately about which mobile platform is best to develop for and how supposedly certain platforms are destine to fail so all developers should jump ship and move from platform X to platform Y.

I’ve just started doing some iOS development myself and I’m already pretty convinced that once I manage to finish my project I will probably have a go at porting it to another platform. You know why? Because regardless of how good I think platform X or Y are or for that matter how bad they are there are, people out there using it and not just a few people a significant number of people.

In my mind apps be they native to a platform or web based are all about spreading an idea to as many people as possible implemented in the best way possible. As a business it is surely dangerous to ignore a platform due to your own personal perception of it. I can understand why a business might not release on every platform because it takes time and resource to port these applications (web based ones maybe not so much), but I think it would be wrong to ignore them through some kind of loyalty to a particular brand.

Over the years I’ve developed in lots of different languages on many platforms. I’ve made various APIs for customers to use and have had to port them over to various languages and platforms and regardless of my views on those platforms the point is that customer is using it, and they probably have very good reason to be using it.

As developers I don’t think we should be taking sides, brand loyalty and being a fan boy is for the end customer, our beliefs as a customer and as a developer should be kept separate and as we develop our software we should be more bothered about how many people we can spread our idea to than what we think about the platform we are developing on. I know it can be hard when the tools are useless and the platform feels clunky but the point is someone out there loves it and uses it everyday and they want to be part of your idea and maybe as developers we’re being a little selfish if we don’t let them in.

As software engineers do we think about software errors enough?

When I say software errors I’m not talking bugs or crashes, I’m talking about the everyday errors that occur because a user has done something wrong or their system is incorrectly configured. Often you’ll find that when writing software you automatically write the code in such a way to best accomodate things when they are going right and sometimes not as much care and consideration is taken when handling the errors that could occur.

My example of this will be MS SQL Server Management Studio. I’ve been developing software for many years and apart from a few courses at university I’ve pretty much managed to avoid any database work. Well a few months ago a project I was working on required me to start playing about with SQL server and this is really the inspiration for this article.

I can’t entirely remember what it was that I was trying to setup but I remember it being done mostly in SQL Server Management Studio and nearly every time there was an error or an issue I was presented with essentially what is a .NET stack trace. Now some of these stack traces were useful as the exceptions that had caused them had useful descriptive information included in them, but others were completely useless in assisting me with working out what had gone wrong. Usually it involved a few minutes googling the issue and I would be able to find the answer which was usually located in the MS Technet documentation. The thing is if they know what the cause is and they know how to solve it then why not include it in the application?

I realise that in large tools like SQL Server Management Studio that lots of different error states could occur and including all that documentation as part of a standard install would make it massive. At the same time sometimes you are provided with a link to take you to more information, I find that 9 times out of 10 that link takes you to a page that claims there is no more information on the error you are having yet searching the site manually usually presents the answer you are looking for.

With complexity comes errors so I believe the route to at least begin to alleviate the above problems would be to attempt to reduce complexity in products or at least shield it from the user. Secondly trying to better document common issues that could occur so that they can be solved more easily, and thirdly include systems within the application that can detect error states and explain the potential problems to the user before they become real issues.

While software now is 100 times more user-friendly than what it was 10 years ago, it still has a way to go and maybe that would be helped if as software engineers we started to spend a bit more time thinking about what happens when things go wrong in our applications.

In software development is it better to be a Jack of all trades or a master of one?

For years I’ve always thought that having a broad set of software development skills is better than being specialised in one particular language or technology, however now I’m starting to question that.

I started doing what I would call proper software development when I started my university course (all those many years ago), up until that point I’d played around with various bits and bobs but never really made anything worth while. Back then everything was new and exciting and learning as much as possible about as many technologies as possible was the thing to do. Over a couple of years I covered many different languages and various associated libraries and ended up coming out of university with a love of C/C++.

Since I’ve been working I’ve encountered many other languages and libraries and I’ve noticed that I spend more and more time learning the latest and greatest of these libraries and languages to keep up with technology. I’ve also noticed more and more specialists appearing and a greater tendency for people to pick a technology and stick with it come hell or high water.

This is why I’m starting to question if it is better to know a little of everything that’s out there or if it’s better to concentrate on one particular area. For example what do employers prefer to see? I interview people every so often as part of my job and I must say that my preference used to be towards people who had a reasonable base understanding in a single language who have then dabbled in several others, however as the company I work for grows my attitude has changed and I now feel that I would prefer people who are more focused in particular areas as it’s only when you start getting in-depth into a technology that you learn its quirks, the kind of things that have a lesser experienced developer debugging problems for hours when in reality there isn’t actually a problem but it’s just a quirk of the framework or because it’s being used in a way that wasn’t intended and it doesn’t want to play ball.

I suppose what I’m saying in many ways is that with languages and libraries expanding at an exponential rate it’s starting to get more and more difficult to know a bit of everything to the level where it can be useful in a real world production environment, where as someone who has dedicated all their time to a specific technology is much more likely to be useful in those difficult situations that can occur and would be more likely to be aware of the issues in the first place and make sure they don’t occur.

While I’m starting to see more advantages to specialising in a single technology I can also see a lot of risks involved. It’s all well and good being an expert in a technology but if no one is employing in that field it’s not going to be overly useful, also there is the issue of flooding the market with expert developers in a single language making employment difficult to find if you chose that technology. You could also potentially lose flexibility by ignoring other technologies or take projects down long and painful routes that could have been solved in a better way had a more appropriate technology been used.

I suppose what might be best is to have maybe two/three technologies as your expertise and then a good overview of what else is available. Maybe it should be Jack of all trades master of some. Reminds me of something a university lecturer once told me. “The difference between a developer and an engineer is that a developer forces it to work and an engineer picks a technology that allows it to work elegantly”.

I’m sure by now everyone has heard of and probably has used Stackoverflow, for those that haven’t it’s a forum style site where people ask software development related questions and more usually than not get actual useful answers. The main key to this is the community driven system that basically means that bad answers (and questions) get put to the bottom of the pile while the goodness floats to the top.

While having a browse around the site a few days ago it got me thinking about how their reputation system works and how in many ways the entire site feels like a big RPG where the point of the game is to help people out.

For an explanation of the reputation system and the awards you can get go the the FAQ section of the site and it lists everything in detail. Basically you can gain reputation points for asking good quality questions or giving good quality answers so this is essentially the same as gaining experience points in an RPG. Once you have a certain level of reputation you are allowed to do additional things on the site and new options are opened up to you, much like leveling up in an RPG. There are even additional achievements for performing certain tasks. Just to finish it off you can also trade some of your reputation points to encourage people to answer your questions.

The above is probably something everyone has already observed and I’m just being a bit late to the game, but I love the way that by intentionally or unintentionally making the site like a game they seem to have brought the best out in people. In the little amount of time I’ve been properly using the site I have to say I hardly ever see any spam or flame wars or me too posts, pretty much all of the content is of a decent quality and I think to a degree it’s because of the RPG game nature of the site. People love to grow a character, gain experience and unlock new adventures and features and more often than not they are very protective over that character and generally won’t do anything to endanger it, seems much the same on stackoverflow, people love to gain reputation points to the degree where sometimes it can be a race to see who can provide a high quality answer to a question first. It would be interesting to know if there were any statistics out there about how quickly questions get answered and those answers get accepted.