This Is Madness!

Jeff Atwood's Coding Horror had this little tidbit about a week ago.  I was intrigued, and went to the wiki for Spartan Programming and read up a bit.  Jeff comes out as more positive towards Spartan Programming than not.

It starts out well - the goal is to eliminate complexity, making the code as simple as possible.  They also seem to have an admirable aim to make sure that things are spelled correctly in code and comments - I can't recall how many times I've cringed because the previous programmer misspelled a word used as a variable all throughout a program.

They prefer the K&R coding style for its vertical compactness, which I disagree with, but that's a Holy War for another time.

They advocate pushing variables as far down in scope as possible, and eliminate the use of placeholder variables as much as possible.  Loops with foreach are preferred to for(;;) loops, etc.

And then they get flaky.  They contend that mere number of characters on a line increase complexity, and so they advocate using very short, even one character names for local variables, and parameters into functions.  This is counter to nearly all the information I've read on how people read - the added semantic information of a meaningful variable name makes code easier to understand, not harder. The next programmer will have a better time understanding the code if the interface has enough meaning to make the usage clear.  There is a small point of matching the domain usage - if writing a function to extract roots of quadratic equations, it's ok to use the common math terms, but I find it almost unbelievable that copy(char *s, char *d, int l) is considered significantly better than copy (char *source, char * dest, int length).

The wiki states that the term "Spartan Programming" was coined in 1996, which makes some sense to me - the author(s) had to have learned programming after the common C/C++ compilers had gained the longer identifiers.  I learned in the era when you had maybe 8 unique characters in an identifier, and I learned that having longer names was a blessing.

La plus la change, la plus la meme chose.  I expect to see someone soon campaigning for assembly as the best way to handle the excessive complexity of C.  With only 3 tokens per line, it is hard to beat!

---

---

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Ninja, Heal Thyself!

Ok, so sometimes you realize that you are not doing everything you need to do.  Today I got a good helping of crow when a new developer was unable to smoke-test a modified API because I did not have a ready-made emulator for the other side of the interface.  I also totally missed a feature of another API, even when I was looking at it (D'oh!) - which led to a day's worth of lost time due to the ensuing concern over the thought-absent feature.

So tomorrow I get to go into That Place and hand out a few dozen mea culpas, and get cracking on fixing those two issues.  I'll help the new developer expand the emulation code we do have to support at least the sequencing we need for the new API calls, and I will volunteer to assist the coding to use that feature I missed and so delayed the development.

I also need to get off my ass and discover some motivation to finish revising some documentation.

All right, enough whining......

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

More Code Kata

More on the benefits of Code Kata

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Cross Purposes (reviews that have no followup)

Sometimes you run across people or departments that have a wholly different understanding of what the job is.  

The best thing to do is to do your best to avoid committing to something untenable in the immediate meeting, and then try to get a meeting with the highest-up person in the other group, to make sure they understand that you do not plan on continuing to let them drive this process.  Reviews are for determining if there are issues, and correcting them via compromise, and only then signing-off.  Any attempt to bulldoze through the correction part will result in even later finishing, due to errors and impossible requirements.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Dynamic Languages

This is a bit old, but Steve Yegge has an interesting talk about dynamic languages that essentially boils down to this:  the problems inherent in dynamic languages are often not significant to your development - they aren't too slow for what you want to do, and the speed of development may outweigh the rest of the problems - if you can get a slightly too slow good version out months earlier, and seize the market, your team can optimize the next version in the spots that are too slow, and you can save time by optimizing the ones your customers really need to be fast.


One bit made me laugh, mainly because I had a similar thing happen to me just last year - "And [my intern] is, like, "well I understand the argument" and I'm like "No, no, no! You've never been in a company where there's an engineer with a Computer Science degree and ten years of experience, an architect, who's in your face screaming at you, with spittle flying on you, because you suggested using, you know... D. Or Haskell. Or Lisp, or Erlang, or take your pick."

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Yet Another VC Who Devalues Programmers

I guess the exchange rate of the rupee to the dollar has gotten all the VCs thinking that because Indian programmers are cheap, everyone else should be cheap. Never mind the relative costs of living.

Auren Hoffman seems to think that good programmers should be willing to be undervalued at the hiring, with the unspoken (and therefor unenforceable) promise of getting more than market value in time as raises are doled out. And this is not even the promise of big money euity - it's just salary!

Tell you what, Mr. Hoffman, how about you take a 20% cut now, just to see if you really want to keep working at your current job. If you're really good, you'll get a raise eventually that will put you above the market average.

What do we have to do to get people to realize that programming is as much work as selling, more being a CEO?

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

When You Can Snatch The Hashtable from My Hand....

Having been out of the academic world for decades now, I'm not up to speed on the teaching in CS/Programming curriculum these days, but various laments from people hiring lead me to believe that many CS grads are being taught to the industry popular things - Java, Microsoft Visual Studio, etc. - and given at most a cursory glance at CS theory. My own coursework was luckily free of commercial value - I was taught in Pascal.

But this post rang true - students are rarely given much chance to develop data structures, or to see why certain structures are better than others. The closest example I ca recall from my classes was an AI course where we were implementing a game-playing program in Lisp, and the alpha-beta tree I was using to find good moves could make about 3 moves before I ran out of time on the machine. I don't know if any of the colleges these days even have limited time on computers any more - other than the sheer clock time limit between the assignment and the deadline.

Given the large number of specialized data structures that exist, it would be hard to do them all justice, but a course that forced the processing of really big data sets would help - driving home the differences between O(n) and O(log n), for example.

Perhaps the availability of truly large data sets - SETI@home, the Folding project, and others, CS can get more meaningful exercises to show the students the real impacts of careless choices.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP