Things like MISRA C make me sad. I wish we were all using better things, be it Ada, or formal methods, or whatever.

Hah! My horrible (truly, truly horrible) code. I mean, the graph output was nice compared to what it replaced, but when I went to rewrite it later (a project that never got fully released, oh well) I wanted to go back in time and back-handed slap myself in the face.

https://metacpan.org/pod/Bio::GMOD::Blast::Graph

P.S. I am a little annoyed that the list could be interpreted as meaning I am not "first author" when in fact I wrote pretty much literally all the code, and was the one who had the idea for the whole project in the first place. Oh well. :-)

I want

"Abstraction without visualization"

to become a software engineering complaint mantra along the lines of

"Taxation without representation"

as an evil to be abhorred.

Abstraction (in the software development sense) kills, in the "news at 11!" sense.

Of course, the lack of it does, too.

sorta stating the obvious, but sad that we tangle them up so.

http://webcache.googleusercontent.com/search?q=cache:lZganwsmysEJ:tal.forum2.org/static/cv/Shakeins.pdf+&cd=1&hl=en&ct=clnk&gl=us

2.1 The Five Facets of a Class

As early as 1971, Parnas made the classical distinction between the interface and the materialization perspectives of a software component. It is only natural to apply this distinction to class definitions in JAVA and other mainstream object oriented languages. In this section we do so, while taking into notice that, unlike the software components of the seventies, classes are instantiable.

Accordingly, the interface of a class presents two facets: the forge of the class, be- ing the set of non-private constructor signatures; and its type, the set of externally- accessible fields and methods as well as available cast operations. The materialization of a class has three facets: the implementation, i.e., the method bodies; the mill, being the implementation of the forge; and the mold, which is the memory layout used for creating objects.

The forge
public Point(int x, int y);
public Point();
public Point(Point other);

The class’s mold
int x
32 bits
int y
32 bits
Fields inherited from Object
Hidden fields added by the JVM 

The resulting type
int x, y;
public int getX(); public int getY();
public void setX(int);
public void setY(int);
// From Shape:
public void moveBy(int, int);
// From java.lang.Object:
public boolean equals(Object);
public int hashCode();
// ... etc.
// Upcast operations:
public (Shape)(); public (Object)();
 

I would like to coin a phrase, a term, an idea in (software) project management: The Curve of Depression.

The idea is that we try to make things, and we inevitably have some bugs. Now, depending on all sorts of variables we each have a subjective reaction to each bug. It ranges from something like "oh good find, QA, thanks!" (the 'good' side) over to "whichever programmer did that should be summarily executed, post haste - even if it was myself!" (the 'bad' side). So there, that's the vertical axis.

The horizontal axis of the Curve is how much improved the thing is when it goes through another round. Did it get resolved in one go? Or has it been dragging on for ever? If there's something really complicated/complex, then (I guess, in some non-Agile sense, anyway) it is OK for that thing to not make much progress so the curve is flatter. Other things that should not have been broken in the first place, or which should really only take 1 more try to get right ought to have a curve that looks like the downward majority of the Winter Olympic's ski jump.

I'd like to know what people's subjective Curve of Depression is that they follow; how they rank things; etc. And then how their projects seem to go. Do they follow the curve(s) well? Do they blow out past them? Do they come in tighter?

"Games people play," but for nerdy software developers: http://www.nasa.gov/centers/ivv/pdf/482488main_4050_-_Object-Model-FeatureGame.pdf.