[lug] can't make this stuff up, folks...

Bear Giles bgiles at coyotesong.com
Mon Oct 19 17:44:24 MDT 2009


NASA is CMM 5 and as I understand it requires every line to be traced back
to a specific requirement.  I don't know if it has to be formally proven as
well.(*)  Medical devices aren't as strict but I'm sure they're also pretty
strict.  Both have high cost-per-line but the cost of failure is enormous.

But DOD? :-)

(*) Provability is an interesting concept and I've used it to find and fix a
few corner cases.  In one case I overheard subsequent developers complaining
about the 'bloat' and about a year later high-fiving somebody else who found
and fixed an obscure bug.  Gosh, I wonder what that bug was and how it was
introduced. :-)  But my experience has been that provability mostly proves
how poorly defined the problem is.


On Mon, Oct 19, 2009 at 5:33 PM, Carl Wagner <carl.wagner at verbalworld.com>wrote:

>  Oops, I did forget that one!
> Except that you phrased it a little bit off: that I must be designed and
> built for pedestrians, but tanks still need to be able to drive over it, as
> well as the occasional reactor vessel (at what around 900 tons?)   ;-)
> And it would be nice if it could withstand a nuclear blast.
> Oh, and your budget is now $6K, and you have one week left so you better
> get busy.
>
> I wonder how much NASA, DOD, and Medical company's pay per line of finished
> code?
> I bet they don't use publically available library's like CPAN, just from a
> testing/maintainability standpoint.
> I would guess that they probably do use internally developed library's of
> certified code. (no bloat)
> I also would bet that they do code reviews of blocks of code < 100 lines
> long.
>
> You can get well engineered software.  The problem is it costs a lot of
> arms and legs.  And it probably does not have a bunch of bells and whistles
> that few people use.
>
> Carl.
>
>
> Bear Giles wrote:
>
> Going back slightly...
>
> On Fri, Oct 16, 2009 at 5:05 PM, Carl Wagner <carl.wagner at verbalworld.com>wrote:
>
>> I would love to see a bridge built with the same sort of requirements
>> that software engineers get:
>>   1)  It must look pretty.
>>   2)  It needs to be done in two weeks.
>>   3)  Your budget is $10K.
>>
>
> You forgot 0).  The bridge must go from somewhere to somewhere else (but we
> aren't sure where yet, just that you'll get it wrong) and we can't tell you
> if it's a pedestrian bridge or it needs to carry tanks but we don't want you
> wasting our time and money by overbuilding it.
>
> I'm sure I'm not the only person who has tried to apply SE techniques and
> been frustrated by the inability of anyone to specify what they want in an
> SE-meaningful manner.  You can't hit a target if you don't know where it is,
> at least not with better reliability than raw chance.  NASA (and avionics in
> general) is an exception since the requirements are extremely well-defined.
> Ditto medical devices.
>
> That's why iterative processes have become so popular.  The inefficiencies
> are more than offset by the ability to focus on the things that really
> matter to the client/customer/boss.
>
> ------------------------------
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#hackingsociety
>
>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20091019/e2e25f0e/attachment.html>


More information about the LUG mailing list