The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Sunday, June 12, 2016

I must learn to live with broken software

I must learn to live with broken software.

When software tools that I have to use are broken, I must work around the brokenness as quickly as possible.

I must resist the temptation to try to figure out what the brokenness is. Unless doing that is quick.   I must not waste hours banging my head against stupid tools like Perforce.

This is especially important for commercial software.   With Open Source software, at least there;'s a chance that I can fix the brokenness - but with proprietary software, that is unlikely.

Although I believe that it is important to report bugs so that they can be fixed,

When something is broken, I need to find the quickest path around the brokenness.


The worst brokennesses for me are the ones that are only a little bit broken.  That mostly work, except for some stupid thing, that one might hope can be fixed with little duct tape and shell script wrapper.


I went looking for inspiring quotes about this topic - advice on how to decide quickly whether it is worth trying to work through versus work around software brokenness.

This is the closest I have come, from the original wiki: http://c2.com/cgi/wiki?DoesSoftwareMakeUsersHappy:  Does Software Make Users Happy: "Techies have accommodated to broken software"

Not so great in context, since the poster is making an argument for SW perfectionism.


That may be the pithy phrase that I am looking for:

How to know when it is better to work around versus working through software problems.

Especially for software that you are using, not producing.

Probably also beyond software.

1 comment:

Andy "Krazy" Glew said...

I swear: if I ever look for a job again, I will make the version control system an important criterion. Distributed, like git or mercurial. Not centralized like Perforce, especially not if intercontinental long distance.