One-JAR is not Shelving.

First article in the shelving series is available here

I just finished up a release of one of my Open-Source projects: One-JAR version 0.97.  This was a major push to remove bugs and add new features suggested by my user community.  How does working a small software project compare with building shelves?

• Both are mechanisms for storage: shelves hold stuff, One-JAR holds software.
• A nice set of shelves for a garage took about 20 hours compressed into five days, from requirements to implementation.  A nice software release took about 120 hours spread over six weeks.
• The shelves should work well for the next 20 years without any attention.  The software will need a new release within six months, probably less.
• The shelves will remain in my garage for the next 20 years, and will be used by a handful of people for free.  The software will fly out around the world, and be used by tens of thousands of developers, for free.   The shelves are an investment in my property.  The software is an investment in the Open-Source community, and grateful payback for all the benefits I’ve had from Open-Source.
• Hardware cost time and money to build, software costs lots of time (which is lots of money)
• Hardware needs requirements and design before building: you have to know what you’re trying to store, and you have to pick your materials and buy from the hardware store, up-front.  You don’t want to get this wrong.
• Software needs requirements and design.  But it’s much subtler than hardware: software has no material cost, and can be re-engineered many times through a project, making up-front design rapidly obsolete.   In some sense, the software is the design.
• Hardware design is physically different to implementation: design is sitting at a CAD program or drawing on paper, implementation is sawing, screwing, hammering, and cursing.
• Software design is physically indistinguishable from implementation: sitting at a computer.  This makes the boundaries blur: when does design cut-over into implementation, and back again to design?  If you use design tools like UML then at least there is some difference between the two, but most projects (in my experience) start with UML, then quickly abandon it as the project complexity grows and implementation starts.
• Hardware is linear: you start at the beginning, you stop at the end, things happen in a predictable sequence.  You can’t install the shelving until the support members are up, you have to build from the bottom-up.  Once the project is underway it’s easy to predict how long the rest of it will take: simply look at the percentage done, and invert it over the hours spent.
• Software is non-linear.  Often horribly so.  The “ninety-ninety” rule expresses this: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” http://en.wikipedia.org/wiki/Ninety-ninety_rule . The problem is, you don’t even know when you’ve hit the first 90% of the code.
• Software is inherently buggy: there are an infinite number of ways for it to fail, but only one way for it to work: the odds are stacked against you, and bugs only show up once you ship the product.  Hardware is mostly bug-free, provided common sense is applied to requirements and materials selection.  Bugs are usually obvious during implementation, not during use.  (Note: hardware does sometimes fail during use, but such failure is rare and unexpected).
• In software it’s easy to re-engineer your entire project half way through (maybe this accounts for the ninety-ninety).  But it’s not trivial to change the choice of lumber once you’ve half assembled the shelves.  Or screws.  Or the requirements.

When it comes down to it, hardware projects are more predictable than software projects because of the constraints of the real-world.  The constraints define the requirements, the design, and the implementation.

The world of software is a world (mostly) without constraints, leading to the Dark-Side of Engineering.  In future posts I will explore risk-mitigation strategies for software development: Rapid Incremental Prototyping (RIP) and Test Driven Design (TDD) – none of which are required in the home-improvement world.

–simon.

The Engineering of Software

The Dark-Side of Engineering.  But there are many dualities between Software Engineering and Home Improvement, which I hope to explore in this blog.  Enjoy.

–simon.

Coda & Loose Ends

So, you remember that earth-fault breaker that was misbehaving that I put off until later?  Well later came, and I diagnosed it in a couple of minutes.  Funny how that works.  Basically, once I took off the receptacle that was tripping the breaker, it was abundantly clear that the wires were loose.  Those breakers work by looking for a live/neutral imbalance of > 5ma, and tripping if they find one.   This is based on the assumption that such a mismatch must be due to some kind of earth leakage, but in this case, I think the higher resistance of the partial contacts of the loose wires was responsible for the trip.  I pulled them out  of their original holes (turning off the breaker first, and jamming in a small screwdriver to release), then pushed them into the spare holes, and problem solved: no more trips.  Glad I let it sit for a while.

But do you also remember I was concerned about whether the 7/16 OSB would be man enough for the job of holding up 200lbs of stuff?  Well it wasn’t.  Within a week it had started creep deformation common with engineered products, bowing down in the center under load,  with an unhealthy gap up to 1/8 inch opening up, potentially leading to failure in the long term.   So I adopted plan-B: putting in the cross-members on the double-height shelves, and the problem was solved:

All told, a successful project, though one which I’m not planning to repeat in the near future.