At my current place of employment, we had someone come in to talk about some Agile development processes.  One of them was Test Driven Development.  As an example, the presenter explained how scoring works in bowling and then asked the audience to create the code used to implement the scoring.

To make a long story short, both he and the audience started with a brief design phase(!) to design something to do something as simple as keeping score.  I thought this was very interesting, even when hearing some of the other developers as they started to design a multi-level hierarchical design for KEEPING SCORE!

I was reminded of an older idea/post that I had regarding the problems when you combine too much formal education with too little practical experience and throw the resulting person into a production-level software project.  Just like when you give a small child a hammer, everything looks like a nail.  When you give a lesser-experienced developer the task of designing something, you are more likely to get an over-design of something that does not reflect reality and tries to attain perfection instead of practicality.

(That post can be found here:
http://www.jrtwine.com/blog/?m=200407.)

What scares me is that some of the developers that were helping along this heavyweight, over-engineered design may now be responsible for new development efforts. I have always thought that you need to be a coder before you are a developer.  That you need to understand how and why things work in order to make better use of them.  As such, I shudder at the thought of having a group of lesser-experienced developers hitting everything they see with the same design hammer.  Especially having seen first hand what they are capable of with something as simple as a scoring system!

And people wonder why I believe that managed environments contribute to the dumbing-down of the modern software developer…

As I am reading a thread on WorseThanFailure (Our Dirty Little Secret), I see a post by “VGR” that states that companies do not recognize “good software”, but rather “finished” or “not finished.”  This is an interesting point.

But a question I would like answered is this – what exactly is good software?  How does one decide that this bit of software is good and that one is bad?  More to the point, since software starts with source code, how do you decide that this code is good and that code is bad?

I have grappled with this question myself, as I am sure others have as well.  I believe I know what good code is.  My education, experience and wisdom are my guides.  But what I believe to be good code is different from what another developer believes to be good code.  Another less seasoned developer may think something else, just as a more seasoned developer might.  So who is correct?

I believe that part of the problem with software today is that there are no common (or otherwise shared) standards for what constitutes good software (or good code which is where good software starts), excluding obvious things like “does not crash” or “does not corrupt data.”

So what exactly makes good code?  Is it…

• Code that just works, or code that works well?  And what is the difference, if any?
• Code that is Declarative, Imperative/Procedural, or just well commented?  Is it a combination of the two or all three?  And to that point, what exactly does “well commented” mean, anyway?
• Code that uses encapsulation as much as possible, because (of course) encapsulation is “a good thing”, or is it code that selectively decides when it is advantageous to do so?
• ??? What else?  I am sure that many other developers have other criteria…

For each of the items above, you can find developers that will argue for one thing or the other.  Worse, you can also find academics with relatively little to no real-world development experience doing the same, cultivating other future developers with the same thoughts!  This is good or bad depending on your point of view.

So how do we solve the problem?  I am not sure that it can be solved.  Software development is both art and science, and that art part is the killer.  Art is very subjective, and one person’s Picasso is another person’s misaligned jigsaw puzzle.  We may have to learn to all just get along here.

There is an interesting thing I am noticing with younger developers – anytime someone mentions optimization, the first words out of their mouths is something about how how the optimization is premature optimization, and is only going to cause more harm than good.

These developers lack a certain wisdom that comes with years of varied experience – once you have experienced something that inefficient, you know how to spot it in the future.

Optimization is about simplicity. Think about it – whenever something is considered optimal, it is usually simplified somewhat from its original incarnation. An optimized interface is usually a simplified one. Optimized code usually takes less steps to do something, and thus is usually less complex; hence – simplified.

From the first Computer Science (or programming) class, the KISS philosophy is hammered in. Keep It Simple, Stupid. The art of optimization is the ultimate application of the KISS philosophy.

Never underestimate or disregard the benefit of simplification, of which is nothing but a better word for optimization. Simple is easier to use, understand and modify in the future. What could possibly be wrong with that?

In talking with a friend I was reminded of one of my favorite WTF moments – correcting the answers on an interviewer’s tech questions. Once, while taking an interview for a position, the interviewer was going over my answers for the tech questions and happened to mention that one (or two?) of them were incorrect.

When I asked about them it turns out to have been questions regarding the size of C++ objects that have no data members. For example:

class CEmpty { };

class CEmpty2 { public:  void MyFunc( void ) { return; } }; 

class CEmpty3 { public: virtual void MyFunc( void ) { return; } };

So what is the size of CEmpty, CEmpty2 and CEmpty3? My answer was that it was basically implementation defined. The interviewer’s answers said that CEmpty and CEmpty2 had a size of zero, and that CEmpty3 had a non-zero size.

I had answered that CEmpty and CEmpty2 will have a implementation-specific/defined size (IME, a size of 1) and that CEmpty3 will have a size due to the vtbl that will be added to the class, and added that the size of the vtbl will not be added to the implementation-specific/defined size given to otherwise empty objects. (In other words, if the size of the vtbl pointer is 4 bytes, the object size will be 4, not 5.)

The interviewer, being a/the senior developer that I would have been working with or for, did not agree and we ended up with some code snippets being compiled and executed in the VC++ 6.0 IDE. Wanna take a guess who was correct?

It turns out that the company’s CTO decided not to accept me for the position. I was never told why (I otherwise aced the interview, of course), but I was told that the CTO created the interview questions (and answers). Go figure…!

Here is another example of code that demonstrates a complete misunderstanding of how things work, or at least of MFC and/or the RTL…

char value[256];
::GetPrivateProfileString("section","ValueName", "OFF", value, 256, INI_PATH);
CString temp(value);
temp.MakeUpper();
if (temp != "OFF")
{ ... }

Now, I can understand the need to do a case-insensitive compare of an INI file value.  But we have functions designed to do that!  Never heard of stricmp(…) and its variants?  OK – even if you do not know about the available RTL functions and all you know is CString, never heard of CString::CompareNoCase(…)?

Code like this just demonstrates ignorance, plain and simple.  Oh, and how goes that exception handling for situations where CString fails to allocate memory?  Oh, yeah…  THERE IS NONE!

Yet another real-world example of useless allocation.