Maurice on Software

When was the last time you developed a product and knew all, and I mean all, of the requirements, before you started implementation; never? That’s right, requirements change, they always change. If you’re developing a product, for yourself, and you’ve created your own requirements, chances are you’ll change what it’s required to do, whilst you’re actually developing it. This is only natural. As you spend more time on a project, you should gain a better understanding of what you’re trying to achieve and how best to achieve it. This holds true when the product requirements come from somebody else. Developers are often asked to develop a product, based on a set of loosely thought through requirements, only to find that the requirements change, when more thought is given to the idea (often as a result of the developer asking for more information because the original requirements don’t make sense). Because requirements always change, it is not reasonable to use this as an excuse for late

I read this book a number of years ago when I was a junior developer in my first job. At the time I had about one years experience developing web applications (Classic ASP, JavaScript, CSS, and HTML) using knowledge I’d gained at University and anything I could find on the internet. Keen to keep up with the latest technologies our development department decided to use, the then newly released, Microsoft ASP.NET. To help smooth the transition, from Classic ASP to ASP.NET, we were sent on a “suitable” week-long training course. Eager to employ our newly acquired skills we returned from the course and went to work hacking together ASP.NET applications in the same, mostly non object-oriented, fashion. Soon after, a new senior developer joined our team and upon recognising my limited object-oriented approach, and complete lack of design pattern knowledge, suggested I read this book. I highly recommend this book if you have: Little or no object-oriented, or design pattern, knowledge. 

Give a man a fish, and he’ll eat for a day, give him a jQuery UI toolkit, and he’ll try to use every bl@*dy effect in every bl@*dy web page. I’ve seen it happen. Don’t get me wrong, I’m a fan of jQuery, and I think some of the jQuery UI widgets, and effects, can really enhance the look and usability of a website. My issue is that whilst its appropriate use can enhance looks and usability, inappropriate and excessive use, can have the exact opposite affect. I should make it clear that I used jQuery merely as an example here and could have used any other toolkit, in any technology, to illustrate my point. A common mistake web developer’s make, once they’ve discovered a new technology, is to attempt to design their user interface around that technology, instead of designing the interface based on the users needs. You will, of course, need to understand what you can achieve with the technologies available to you, but you should strive to design the interface first and then select the bes

When was the last time you asked your manager for something? They’re not just there to give you orders and make your life a misery, you know? OK, so there are lots of good managers out there. I’ve been lucky enough to work with managers who have, for the most part, been supportive of my personal development needs. I shouldn’t really refer to it as luck, although, of course, there has been an element of luck involved. I prefer to think that I’ve selected my managers, and in a way, I have. I might not have recruited them to their positions but I certainly vetted there suitability during my own interview. I’ve turned down a number of roles because I thought it would be difficult to work with the person interviewing me. But what if your manager wasn’t at your interview? That is when you must take responsibility to, as an ex-colleague of mine used to say, ‘manage your manager’. Managing your manager involves making sure they know what you expect of them, in order to make your job easier and

Prototyping your software is a great way to prove to yourself, and others, that you can get something to work. One of the first goals when developing software is to make it work. And herein lies the problem. As soon as you demonstrate your software to the user, or your manager, or any other interested party, they will assume that it is ready to use. It doesn’t matter to them, that it’s a ‘Prototype’, what they can see is a working product and they will want to use it straight away (providing it does what it was intended to do). What if you deliberately made it look bad? What if you deliberately made it error? They certainly wouldn’t be so keen to roll out the red carpet and put the champagne on ice. Perhaps, introducing faults into your prototype is slightly OTT, but it is important NOT to give the impression that the product is near completion and thus create false delivery expectations that you may be unable to meet.

The term ‘bug’, is widely used in software development circles, to describe a fault, or defect, in software. Your average dictionary will confirm that the word itself has many meanings, and usages, in the English language. It is because of this wide usage, that I find it strange that the word has been embraced so readily, by software professionals. A developer claiming that their code is “bug free”, gives the wrong impression that the software is perfect, regardless of the many other criteria that need to be meet before ‘perfection’ can be achieved. During testing, Product A was found to have significantly fewer bugs than Product B, yet Product A poses the far higher risk due to the nature of the bugs found. Perhaps we should introduce the concept of ‘nasty bugs’ and ‘cute bugs’? Maybe not, but we should definitely consider using different terminology, to describe software faults, and crucially, understand the impact, that different types of ‘bugs’ will have, on the quality of our so

It’s not long after you’ve released a new product, or feature, and the call comes in that something is not right. Should have done more testing, yes? Well, maybe. What if you couldn’t do more testing because you just didn’t have the time? In hindsight, should you have factored in more time for testing into the planning phase? In order to answer these questions we need to understand what we are trying to achieve when we test our software. We also need to consider the nature of the projects we are working on, the composition of the development team, and the cost of testing. What are the goals? I opened this post by saying “…the call comes in that something is not right”. I chose these words carefully. By saying that something is not right, what we are actually saying is that the product is not behaving, or does not look, as was intended. It is not great software . When we test our software, we need to go beyond, simply ensuring that it doesn’t throw errors, to making sure that it

There are a huge number of articles on the web about "How to Comment Your Code" or "10 Top Tips to Comment Your Code". Having read a number of these I noticed the apparent absence of context in the advice given. Without a context it is easy to argue that one approach is better than another. Some people will argue that "all code should be commented", others that "if you write good code you don't need to comment". Both statements have value but without a context neither is right or wrong. In this post I'm going to discuss a number of approaches and suggest in what situation an approach is most suitable. Comment everything If you've ever used the Microsoft .NET Framework Class Library then you're most probably familiar with the MSDN style of documentation. You too can easily achieve this style of documentation, for your software, by commenting everything in your code and pointing a documentation tool (e.g. Sandcastle) at your

Often one of the most difficult, but important, things to say is "no". I've learnt this the hard way. As a junior developer, in my first job, I was so eager to impress that I said "yes" to most requests. Big mistake. Very soon I discovered that I didn't have enough time to do what I'd committed to and often didn't have the skills to do it either. Now it's not always easy saying "no". I used to worry that I was letting people down and that they would think I was being awkward. In the end though, I let them down so much more by not delivering on time or sometimes by not delivering at all.

I used to work with a developer who used to go to the toilet and come back with the solution to his problem. Now I'm not suggesting you spend your working day hanging around toilets (probably wouldn't go down too well with your colleagues), but the point is that by simply taking a few minutes break, and walking away from the problem, you'll be surprised by how often the solution will come to you.

Take a small amount of time each day to learn something new. Doing this every day will amount to a lot of learning. This might sound extremely obvious. However, if you don't make a conscious effort, to learn every day, it's easy to become complacent, and you'll soon find yourself lacking knowledge. This applies to most industries but is particularly relevant in software development, due to the rate at which technology changes. If you're lucky enough (or maybe not) to work on different types of project, and/or with the latest technologies, you might argue that learning is just part of the job. In this scenario you'd be right. However, there will be times that you have to work on the same project for a long duration of time. Usually, the start of the project involves lots of learning, there's a need for research, and you might prototype possible solutions. Learning is part of this process. When you come to the implementation stage though this naturally slows do

Updating your CV isn't just something you should do when you're thinking of applying for a new job. Updating your CV, especially the skills section, forces you to reflect upon what you've learnt over a given time period. This can have a number of benefits. If you find your skills are improving, either you've gained more experience in a certain area, or have gained new skills, updating your CV will give you confidence, and reassurance, that you'll be attractive to employers in the future. If you find your skills are staying much the same, over a period of time, it should provide the wake up call you need to re-evaluate your situation and make appropriate changes.

I overheard a conversation/argument a few days ago between two developers. At one point one of the developers said “well my product is greater than anything you’ve ever done!” It’s a shame the other developer didn’t respond by simply saying “prove it”. How could the first developer prove it? Proving whether a product is great or not depends upon how well the product fulfills its intended purpose . If a product was developed with the intention to annoy everybody who uses it, and it does, it’s a great product. If it doesn’t annoy the users, it’s not a great product. Of course, this would rarely be the intention for a product, but it illustrates a valuable point. A product doesn’t have to look good or work perfectly for it to be great, unless that was the intention

As I mentioned in The Beginning , I value my spare time. I’m not going to be able to spend loads of time writing lengthy posts. I’m also aware that, the lengthier the post, the less likely you are to read it. That said I am keen for this space to evolve and grow. I am going to use something I’ve decided to call Bites . These will be short sentences designed to stimulate thought on a certain topic. They might, simply, be a question, to which I will offer no answer, or maybe an observation. Whatever the format, the important thing to remember is that Bites will be as useful as you make them.

I like to have a focus. This blog needs a focus. This blog is going to focus on software development in small to medium sized businesses. I’m not going to focus on any specific industry, as the principles discussed apply equally well regardless. My decision to focus on small to medium sized businesses is simple. It’s whilst working in these environments that I have gained my experience. Although I’m not focusing on a specific industry it should be obvious that the information technology requirements of a business will differ greatly between industries. Where appropriate I’ll try to provide a clear context in my posts to help you judge their suitability to your own circumstance.

I've been a software developer for about 7 years. I've enjoyed it, mostly. I've learned a lot. I’ve worked pretty hard but I’ve never been one for working long hours. I value my   spare   time too much. I recently,  officially,   started a new role as a program manager. The role, actually, isn’t quite that clear cut (are they ever?) as it involves some line management responsibility also.     I’m going to use this space to document my thoughts on software development