All software is a work in progress none is ever perfect. It will always have bugs, sometimes it might even seem that the software is nothing but bugs an it's in these dark times when we normally say fuck it, let's start over. Not always, some of the good excuses I hear for a rewrite are:
By all accounts the property market is in free fall and we're taking the possibly bold decision to launch a product with estate agents as our primary market.
The product is called Citrus and it's better way for agents to sell property online because frankly the existing solutions are all pretty lame. We got here through our work with a good friend Colin and his spanish property business Spirit of Granada. In developing the website for his business we realised that the existing solutions weren't easy for a small company or sole trader to work with, they involved lengthy contract terms, high costs and confusing feature sets and options. We want to change all that and think that our insider knowledge of how these smaller agents operate will allow us to build an application for the market that doesn't suck.
Stay tuned to find out.
Bugs, in an awful lot of organisations they're a four letter word, they just shouldn't happen. But unfortunately despite the shouting and stomping, they still will.
your software has bugs
Your software has bugs, go ahead, say it, try it on. Does it scare you? It doesn't scare me. I know mine does, this isn't a shock, revelation or epiphany for me. I had that years ago:
One dark stormy night with a start I sat bolt upright and realised I wasn't perfect, that I couldn't write perfect code. I sat through the rain and the thunder awake and frightened, but as the sun broke the next morning it a clear new day dawned on a world washed free of it's sins. I felt renewed, rejuvenated; I bounded to the office, spearheaded an overhaul of our development process, got a more agile workflow implemented with fast iterations and complete management support.
Ok, it wasn't quite like that. I was actually up all night because someone somewhere had been freaking out about yet another bug the day before. It was affecting one user, and it would only be a matter of time before it would be affecting others - then like dominoes all of them; soon they'd be the rats leaving our sinking ship upstream and they'd take the paddles with them - in short: DOOM!
It's very easy to find a bug, say it's obvious and should have been tested, it's quite another to test all the functionality and find all of the bugs before launch. My software has bugs, so does yours and everyone else too.
get over it and stop blaming others for your problems
Bugs are a result of code, written by programmers- but it's not always just the programmers who are to blame. Organisational pressures leading to scope and feature creep, poor design and processes or a lack of any sort of roadmap will all contribute to the problem.
So many times I've been working to a deadline (beginning, middle or end - it doesn't really matter once a timeline is fixed any changes will incur a cost), then someone comes along and starts a sentence with "What about..." and totally blows the schedule. The problem is people rarely take into account the very simple fact that the schedule wasn't set to include this new task, or the next next one.
This schedule pressure then leads to rushing either the design, the testing, the coding or all of them - this more or less ensures there will be more bugs.
Common excuses I hear for this are:
It's obvious, and should have been thought of. Sometimes this is a valid comment, but I have never been part of a team where the obvious was actually missed. In my experience this has almost always been used as some rhetorical comment to excuse someone for not mentioning a feature until launch or later.
If we don't have that for Friday's launch, we won't get customer X
Adding would mean getting so many more customers This is such a great trap for a business- so good I'll be writing much more about it in the future. Oftentimes it's political or the result of an organisation without any clear goal setting or planning.
Schedule pressure is often further exacerbated by not making any allowances for bugs. If you don't make allowances for fixing them post launch, you've already missed your next deadline.
what can we actually do about them?
There are a few things we can do organisationally and individually to lessen their impact. Start by not being afraid of them, accept they're a fact of life and get over it. Shit happens, and it piles up - get a shovel or get out of the way. Look to the processes and people and streamline the development workflow. Everyone involved needs to think things through. Finally once you've accepted bugs, worked to minimised them in development deal with them calmly and rationally, if at all.
deal with the workflow issues
If your development processes seem to be creating a lot of bugs, they're the fist place to look. These are going to be the hardest to change, but they'll also give you the biggest returns. A few of simple steps to take:
Design the interfaces first Changes to desgin mid-stream cost at any stage of the cycle, but the earlier they're discovered the less of an impact it will have. At least wireframing your interfaces means everyone gets a good look at them before development starts, and can say "what about..." early.
Remember changes cost When someone asks for a change, make sure you point out that changes will affect delivery. Ask them why it wasn't thought of earlier. Don't take anything as read and make sure nobody else does either.
Iterate often Small quick iterations mean features go into use quickly and mean less changed code and less places for bugs to hide. This also allows bugs to form part of the next iterations work.
all bugs are not created equal
Not all bugs will affect people equally. Minor display issues are not as important as an issue where user data is randomly disappearing. An issue where the front page of your website is full of gibberish is far more important that a newsletter not being sent on time.
All bugs should enter a triage system, where the scope of the problem is analysed and a prioritisation decision is taken. There is no room for rhetoric, blame or politics in this process and clear descriptions of the problems are key. The title of this post is verbatim the subject line from quite a few emails I've seen in my life, the body is usually not much more helpful and generally descends into politics and conflict. A minor display issue affecting some users is hardly "irreparably damaging", "actionable", cause for anyone to "seek any and all legal recourses for reimbursement or compensation" or cause to run off and offer the person our most heart felt and abject apologies for the inconvenience.
We need to step back, look at the extent of the problem and respond appropriately. Going off on one while a wild wacky tale to tell alter, isn't really professional or productive.
Which leads us to...
not all bugs need to be fixed immediately, or even at all
In a perfect world, we'd fix every bug as soon as it was reported. Then again, the world wouldn't be so perfect because we've got a bug in our code... in a slightly more perfect, yet undeniably imperfect world we'd like to fix bugs as soon as they happen. This isn't always going to be possible and for various reasons it may not make sense to fix a bug immediately.
Take for example the following completely hypothetical situation. You've got a bug in some obscure import routine written for one customer a year and a half ago. The sales team promised it was going to be the next big thing, would open the door on a whole raft of customers that used that package - it turned out to be just the one and they may or may not renew their contract in six months time. Politics aside, given certain situations the import fails and you might choose to just not fix the bug
They're unlikely to renew and fixing it isn't going to sway them or get you any new customers Don't fix it and just remove the whole broken import from a future iteration. Chalk it up to learning and plan new features better so you're addressing the needs of your users
A work around exists Your time might be better spent elsewhere, especially if the problem only affects a single or small number of customers
Planned developments will obsolete the feature A reworking of the feature, section or other areas of your website, the integration of a new API or a new workflow or way of doing things may mean the bug just dissapears in a future revision. One caution with this, as with any bug fix the promise should be delivered to the cusqtomer on time
A friend of mine, Duncan is starting a new business and needs a website. He's importing high end mountain bike components and I'm pretty excited about it. I know I shouldn't be planning to spend money on a new bike frame - I should be saving it for important family things, but the frames look great, anyway I digress.
Duncan needs a website to promote the business and knowing us, we were an obvious choice. A few weeks ago he called me to chat about it and we arranged a meeting. He's done a great job of setting the ground work, has taken some great action shots of the Zambi frames with a pro phtographer. All he needed was a great site to help him sell.
Simon [goroam cofounder] and I had a discussion about where we were going, what we wanted to do and how we wanted to get there. Our conclusion was: we're too busy to take on a the website in the next couple of weeks and give it our full attention.
So we met up, bought him lunch and told Duncan straight that we were too busy. We talked about alternatives and suggested working with logoworks.I didn't like to dissapoint him by not taking on the work - but I think long term it would have been more disapointing all around if we had. Instead I've offered to give him a hand with any helpful advice he needs to get going and we opened the possibility of later working together to develop and promote both his website and online marketing strategies once the initial design work was done.
It's hard to say no to work, and money when you're a small company, but sometimes it's for the best. We wouldn't have been able to do as good a job as either we or Duncan wants if we did agree to take the work, and we wouldn't have been able to deliver it in a timely fashion.
check him out
Duncan has already spoken to another designer and should get the site he wants soon. When it does go live, and if you're looking for top of the line mtb gear give them a few days to sort the site out then check it out, All Mountain Imports
Welcome to my new blog. I've tried a couple in the past and haven't managed to find my voice and get them going, but I'm going to try again. I'll basically be talking about bootstrapping our company, coding and other things I thing are interesting or relevant but I can't promise any of it will be well written, or interesting to you, though I'll try. You can help by letting me know what you think is good or more importantly what you think is bad in the comments.
The design is close to what I imagined, but I'm no designer. I can beat things into a rough shape approximation what I think would look good, but I can never get the smooth finish I'd like. As with the writing I'll work to improve this as I go.
This is a conversation, the comments are as important as the posts and it's a fine line to tread. I'm not setting out to moderate the conversation in any great way; I don't have the time or inclination. I'll largely leave it alone and respect constructive criticism and comment. I won't respect attacks personal or otherwise though and will delete any and all comments which set out to disrupt the conversation
I'm a sell out
There are no ads on here at the moment, but one day when there are pageviews I'll probably put them on here. I reserve the right to sell out at any time - so it's probably best if you just consider me a sell out from day one. You can quote me:
Andrew McCall is a sell out, he uses his blog for personal financial gain and to shamelessly plug businesses, products and other things which will either directly profit him or people he knows.
So there you have it, my latest effort is launched - please stick around, hopefully enjoy and hit the comments to let me know how I can make it better.