bullet proofing software

The difference between a proof of concept and a final piece of software that is to be used in the wild is the amount of bullet proofing required by the latter.

When the first beta of BlogEd came out, it became obvious to me that some people here were using BlogEd to write some pretty serious blogs, with some entries going on for a few pages. Each of these can represent a lot of work. The last thing I wanted was for my software to be responsible for them loosing their entries. Sure, loosing a blog entry won't be as bad as making a mistake in a banking application, and sending millions of dollars to the wrong account. But then banks have some very heavy weight processes to help them along, whereas I am all alone, to write test and debug this application.

One tool that helped a lot was JUnit. I don't think I have been using it enough, and I have not yet worked out how to use it for GUI's but it is clear that I would never have had the confidence to get some aspects of BlogEd done without such a tool.

Another aspect of the bullet proofing is making sure your software does not do anything un retractable without telling your users, and asking them for their opinion. When publishing with the meta weblog api, this means any time anything goes wrong the user has to know about it, as there is so little one can rely on.

Then there are those weird corner cases such as two instances of an editor having acess to the same database. This may not happen often, but it is clearly worth defending against as the damage done by that could result in some very difficult to understand bug reports.

That in summary is what has been keeping me busy with bloged for a little over a month now.

Comments:

Post a Comment:
Comments are closed for this entry.
About

bblfish

Search

Archives
« September 2015
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today