I got this proverb from an italian friend who was quoting his grandmother. This means litterally "who spends more, spends less". I've been thinking about it for some time.
First, this was the argument that made me go for my new Bose bluetooth headset, which is quite expensive. I bought a Bose Mini Soundlink some months ago and I am completely happy with it. It was also not cheap, but, the counterparts:
That's an investment. Unless a disruptive change in the Bluetooth protocol, or its complete fall, I'm good for five to ten years of good sound, plus the rest. Which is at lightyears from a cheap one that I'll have to change every twenty-five months, as it is guaranted for two years. Of course, four of them would cost me less than half the price of that one. But it's not the same sound, the same portability, etc. I enjoy quality from day one, for a long time. And I don't have to look for another one, bother with wires, etc. I chose to spend more to spend less. Which led me to buy this crazy headset, which is not cheap, but oh dear, worth the price. And now I don't need to think about the next speakers or headset I'll have to buy, I just enjoy them.
I believe the same applies to software engineering, at least. We can think of many other fields indeed, and that's part of its beauty, but let's focus on that one. You should see by now that this proverb is not only about investment, it's also about quality. The central point of this post, this proverb, can be translated as:
Invest in quality
It's really worth it. You can outsource parts of your code. It looks cheaper at first sight, but the time you spend checking the work done, the communication, the maintenance, etc, all of this ends up to be much more expensive than a full-time employee who's going to feel the project, pour her soul into it, document it for herself and her colleagues, write the right tests, make sure the integartion is flawless, and so forth, will be much more valuable than a remote disposable stranger.
Investing in quality means also investing in quality procedures. Making sure that the build doesn't break. That the code coverage is at a reasonable percentage. That the performance is at least kept, if not improved. That the code is properly reviewed. That interfaces are enforced with a scripting language or another type of API. That time is taken to probe ideas, to write a prototype, and then to throw it away once the conclusions drawn, instead of trying to recycle it.
There are indeed the laws of the market, where sometimes you have to release a non perfect version to be first, ahead of the competition. Yet, it doesn't forbid you to catch up quickly, backed up by the right quality procedures, and a proper user follow-up: what they like, what they don't, what they truly need, how to improve the software to solve their problem. You'd be surprised by how much users appreciate to contribute to a high-quality product, and to feel part of it.
Now I'm thinking that it's exactly what I did when I started with Haskell. Coming from geoengineering, it was quite a time sink to make the paradigm shift. Read many books, from functional compilers to category theory, alongside the mailing lists. Wrote tons of throw away code that I ended up improving when I understood more the practice of functional programming. But now that it's done, now that I have invested in quality, I enjoy it every day. I don't write Haskell code every day; far from it. But the new angle it has brought to the code I do write every day is invaluable. Not to mention the code I want to write, as pet projects, to see how to answer the questions I have with a more functional approach.
I like this proverb because its simplicity resumes the path I have chosen. I invest in quality. I still haven't figured out many of its second meanings, but I know I won't be short on good surprises.
June 30, 2015