Home	Who are we? Contact us. About Reliable Software

So why do we put up with low quality software? Let's think about it. A car usually breaks down because of wear and tear. What is it that wears out in a computer program? Do icons fade? Do the menus break off and fall down on the status bars? Do bits and bytes deteriorate with frequent use? The truth is that all the bugs you discover using your system or application have been there from the beginning. You were sold a defective program! To continue with the automotive analogy, it. s as if you were sold a car with a design flaw. A leaky gas tank. A slipping clutch. What happens in the automobile industry when a potentially dangerous flaw is discovered? The cars are recalled!

Have you ever heard of a software company recalling a program? Well, program flaws are not that dangerous. The worst that can happen is that you lose some data, waste a few hours or days of work. No big deal! And before you report the problem to the manufacturer, check the readme file or the last minute documentation. Oftentimes you'll find a list of "known problems" and some creative workarounds. If you decide to call the company anyway, remember that you'll have to pay the (usually long-distance) phone charges while they put you on hold, play Muzak, and make you listen to their pre-recorded ads. And what do you expect to hear once you reach a technician? That the bug will be fixed in the next version which is supposed to ship "real soon now"?

How can software companies get away with this? Because we let them. Don't get me wrong-- I don't think they do it out of malice. They are driven by market economy, they produce software that sells and they try to minimize their costs. So as long as users keep buying low quality software, companies will keep making it. And the users have little choice because everybody is producing lousy software. So either you buy it or you let your computer grow cobwebs.

Is it possible to make high quality software, and would it be very expensive? Yes, it is perfectly possible and yes, it would cost an arm and a leg, using current technology. You see, what happened was that the software industry cornered itself. Let me explain: Relatively speaking, software costs nothing to produce. This is why there is so much cheap shareware and freeware that can be got for the price of connecting to the Internet and downloading it. That's right-- when you buy a software product, you pay for marketing. Only a few cents per package goes back to programmers who wrote the code. Of course, multiplied by the number of boxes, these cents add up to quite a hefty salary and attractive stock options. Programmers are not paupers! Still, from a software company's point of view, programmers are cheap.

Hiring more programmers is the standard answer to most problems facing software companies. They call it increasing the headcount (as if they were dealing with cattle or hogs). The problem with this approach is that it leads to further deterioration of the quality of their products. Not only because there simply aren't that many top notch programmers on the market, but also because of the tremendous overhead of large team work. In software development the inter-dependencies between various components/developers grow exponentially with the number of components/developers.

You can also make programmers work harder, work them during weekends and holidays and make them feel guilty if they don't. After all they are paid a lot (relative to other professions, if not to the revenue they create). If your programmers work harder, you need fewer of them and you cut down the overhead of large team work. This approach also has its limitations. First of all, the really smart programmers can see through it and they sooner or later quit. Second of all, in order to do quality programming you have to have a clear mind. And once you start hallucinating after staring at the monitor for twelve hours, the quality of your work goes down the drain.

You'd think that software companies would try to provide their programmers with the best tools money can buy, if they cared so much about increasing their productivity. Well, you'd be surprised to find out that many programmers have more powerful computers at home than they do at work. Programmers love large high resolution screens. They provide more real estate to display all the files they work with, plus the output from the compiler, plus the e-mail, plus the stock ticker (to watch their stock options grow). But big monitors are expensive, so they are mostly for the managers.

Surely there must be a lot of software tools that make programmers more productive. You'd think a big software company must spend lots of money not only buying the best tools, but also developing new ones for internal consumption. Well, guess again-- Why do you think they should spend money on tools if they can simply hire more programmers. And where do they put their best programmers? They put them to work on their company's main product-- not on some useless tools. There is no time to write tools! And most definitely there is no time to switch to some new untested methodologies (also because most of them turned out to be useless in the past).

This vicious circle will continue until the situation becomes so bad that a paradigm shift will have to occur. And this is where Reliable Software comes in. What we are trying to do is to prove that high quality software can be created in the environment where: There are just a few good programmers, They follow a methodology that ensures high quality and productivity and They have the best tools to support this methodology and automate everything that can possibly be automated.

We want to prove our point by following our own preaching and achieving commercial success. In other words, we are putting our money where our mouth is. Since currently there are no high quality productivity tools for programmers on the market, we'll have to create our own. So this is where we start. Please visit this site from time to time to watch our progress. We'll be quite open about what we are doing, since we have no competition to speak of. We will also provide previews of our tools, free demos and free gadgets for downloading. And we are planning on making our methodology available to everybody interested in it (a book is in advanced stages of preparation).

How many programmers are we? Four. Just watch us!

Bartosz Milewski President, Reliable Software

It took 10 years and $7 billion to make. It took 1 bug and 40 seconds to destroy.

Ariane Flight 501 Blew Up. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. For more details see the results of the ARIANE 5 disaster inquiry.