views:

121

answers:

4

What is the "non-software" development aspect in your environment that has helped you in making your software more usable, secure, robust, and resilient (apart from it doing its job)?

I will elaborate on my experience. I am a developer in a country where electricity failure is a common place. I worked in a research lab at a local University few years back during summer. I was developing a code to parellize computations for large chemical systems. I had access to a 32 node cluster with a UPS backup. These computations would easily take days to complete. Electricity failure was a routine. So everytime there was an electricity shutdown/failure, i would log in to each of the nodes, save the state of the running processes. This happened for over a week, and then i was too frustrated to perform this task. It made me feel dumb! Slowly i started building in fault tolerance in the code that i was writing. Thus when the processes would come up (when the electricity is available) they would start executing from the point of failure rather than starting over again. Over a period of few weeks i added redundancy in job execution by spawning off multiple background jobs with low priority on commodity(user) machines. At the end of my project, i was very happy to build a software which was resilient to failure (apart from computation which was THE job).

I really thank our government for not providing us with enough electricity. I was thus able to build a software which can react to situations of high failure and in turn learnt a lot :).

I would love to hear your experience.

+2  A: 
T.E.D.
I got annoyed at my Vista box and, lacking anything practical to do, decided to threaten it with a Ubuntu Live CD. It's still sitting on the computer, doing about as much as your spider.
David Thornley
+1  A: 

In the 20 years I have been in the business I have come to believe that Murphy was an optimist. I would learn to be defensive - checking for errors, unexpected ranges for values. Once you know this I would learn the techniques in programming that support this pessimistic view of the world - exceptions, asserts, design by contract etc.

It has never been that we didnt plan for something to go wrong, just that we lacked the imagination that something could go wrong in such spectacular ways.

MikeJ
+1  A: 

I worked as a graphic designer for a few years. That experience helps me daily in the design of software UI, from the layout to the usability.

JimDaniel
+1  A: 

"Lightweight" code reviews are a great idea. They are typically performed via software, of course, but per se aren't software, so I think they qualify here. (version control systems, automated tests, etc, OTOH feel like "intrinsically software" aspects;-). Whiteboards and their markers, and post-its to go with them, are a close second...

Alex Martelli