firebug

There are 2 posts tagged firebug (this is page 1 of 1).

iterative development

We’ve all had it drilled down our throats that development should be completed in short-sharp iterations. “Release early and release often” – no agile developer gets up in the morning without repeating this mantra to themselves before they reach the sink. However, surely it’s important to realise the difference between “Release early and release often” and “Release utter shit early and release utter shit often”.

Who really wants to use an application/toolkit/library that has so many bugs in it that the user experience is dreadful? Surely users would rather wait a few more weeks for something that is, in a sense, polished? I mean we’re not talking Microsoft Vista style release cycles here, but quality control consisting of a little more than running a set of unit tests would be nice.

So what has prompted this minor rant? Well Firebug unfortunately. I hate to criticise it because it’s free but the bugs I find in it are getting worse and worse. The most recent one being that the continue button no longer works in the latest release (1.4.0b10). Sigh. However, open source or not, my feeling is that if you choose to do something then do it properly or not at all.

Anyway. Regardless of the product, it surely makes more sense to sacrifice your release schedule a little for some real testing and bug fixing? For commercial products a bad user experience is going to make a sale difficult both now and in the future. Being first to market is one thing, but it’s far from being the only (or even main) contributing factor to a products success – Google and Facebook being good examples of this.

So is it possible just to have a little common sense about all this and maybe restate the mantra as “Release quality early, release quality often”. It can’t be that hard, right?

is open-source software worth it

I’ve been having some real problems with FireBug recently – essentially it has made itself utterly useless. Why? Well when I set a breakpoint within FireBug and that breakpoint is reached, the code window does not scroll to the breakpoint. I then have to drag the scroll bar down to the breakpoint, then when I press F10 to perform a step over, the code window resets itself to the top. As you can imagine this get rather annoying after a while, especially with large JavaScript files.

As a result of these misgivings I have found myself using the IE8 developer tools – which are actually quite good, though FireBug, when working, is better.

Luckily the project that I’m working on is not exactly critical, though the quicker I get finished it the better. However, if I was working on something that was going to generate me $$$$$$, I’d hope to god that I wouldn’t have to waste so much time with the debugger. With this in mind, and with the mindset of “You are a dumb ass if you fail to utilise open-source software” prevalent in our industry, it raises the question as to the limits of open-source software.

If the software that you are developing is largely based on open-source/free software, and this software sells for hundreds of thousands do you really want to be using libraries that have no real service-level agreement? For example, let’s assume that your software sells for $200,000. Then it’s safe to say that your customers will be expecting some pretty good service for that kind of money. Suppose a bug is found in some third-party open-source library that is used in your product. So you have two options: 1) you ask the community to fix the bug or 2) you fix the bug yourself. Are any of these really a satisfactory solution? I don’t think so.

Consider option 1. Suppose that the project stagnates or your bug is just not an issue for the community, then it may take some time to get this bug fixed (or they may not fix it at all). But you need this bug fixed yesterday! People tell you “Oh there is always someone in the community willing to help”. Nonsense. There are no guarantees and this is exactly what a professional organisation needs. A bank, telecom company, utilities company and so on are not going to give a shit that you can’t get it fixed soon, they will just move their business elsewhere. This is the reality of the situation, and if you are moving a core part of your business out to open-source software and charging a small fortune for your software, I’m pretty sure this is going to come back and bite you. Open-source software proponents can scream until they are blue in the face that this will not happen, but it might, and that’s all that matters.

So if option 1 cannot save you then your left with option 2. Well first, it’s easy to say that you just get the source and edit it yourself, but the fact of the matter is that it takes quite some time to be comfortable with a large code base. In particular, to be comfortable with the fact that making changes in one place doesn’t cause problems elsewhere. OK, unit tests help, but there are no guarantees. Maybe you could be involved in the maintanence of the open-source software on a regular basis to ensure that your team has built up a familiarity with the code. Maybe even developing new features etc. That sounds like a great idea. Until your competitor comes along and uses all these lovely features that you have so kindly developed for them! Then how much of a fool do you look.

The fact of the matter is that if you write the code, then you have more control over it, and this eliminates any dependencies you may have on outside parties. The more you charge for your software, the tighter your service level agreements are, and the more third-party libraries define the uniqueness of your product, the more important this becomes.

This is not to say that we should all go out and write our own compilers, IDEs, and various other things. It’s just a matter about being sensible about what you use.