Tag Archives: software_engineering

Uncategorized

Making software better

I’ve now been at work for 15 hours since I last slept, most of which has been devoted to tracking down a problem that makes me want to rip my hair out and a large chunk of which I won’t get paid for.

However, that’s not a big deal :-)

Along the way, I needed to look at a lot of ‘printf’ output. Normally, our software doesn’t spew a lot of debug information. We print a certain amount my default because it allows our customer to self-diagnose to a degree – but if we print too much, the customer freaks out and that makes more work for us when a vast majority of all of our output is purely informational. Even some messages that say things like “ERROR! THE WORLD WILL EXPLODE IN 10 SECONDS” can safely be ignored, so we keep most of our debug output off.

What that means to me tonight (this morning) is that I need to turn it on. Ok, great. There’s one line in a config file somewhere, right? Or maybe just one runtime “knob” (that reminds me, I should write a post about knobs) that can be turned? Heh. Wrong.
read more »

Uncategorized

Engineers don’t get capitalization

They also don’t get a number of other things, like punctuation and grammar.

When I was in 1st grade, my teacher gave us an assignment to write something – you know, on those tables with the huge writing lines with the dashed line in the middle so you’d know how big to make your lower-case letters.

Anyway, I asked the teacher if we should use capital letters or not. She said something to the effect of “Either one is fine.” As a 7-year-old, I interpreted her a little too literally, and I wrote things like “I WenT tO ThE paRk.” My grade on that assignment was really low, and the teacher explained that she meant for us to use capital letters all throughout or not at all.

Engineers aren’t much better. What’s even more surprising is that these documents that I’ve read were written by senior engineers who have written numerous documents like these and are very highly paid. The documents I’m talking about have phrases like “Signal Sample Rate” and “Tuned Signal Bandwidth” where they should be “Signal sample rate” and “Tuned signal bandwidth.” These are pretty benign examples – there are far worse ones, but I’m not permitted to reproduce many of them here.

It’s baffling to me; I have no idea why it seems to some engineers that words like “signal” need to be capitalized when they aren’t proper nouns or part of a title or any other category of words or phrases that need to be capitalized. It’s very distracting to read documents like this because instead of focusing on the subject matter, I think about how badly the document was written.

Update: I just realized that I previously wrote a post very much like this one. I’ll leave this as is, but add that the duplication illustrates that I see poorly-written documents on a regular basis. I’d be embarrased if I wrote such a document.

Uncategorized

Whose Distributed VCS Is The Most Distributed? – The Changelog

Whose Distributed VCS Is The Most Distributed? – The Changelog

A good read on the more recent tools available. Included is:

  • SVN
  • GIT
  • Darcs
  • Arch
  • baz
  • Mercurial
  • bazaar-ng
Uncategorized

Good Agile vs. Bad Agile? Earth to Google…

Stevey wrote a long post today on the development environment at google, and what “agile” means there versus the meaning of the “Agile Programming” methodology that is all the rage right now.

It’s a good post, and the comments section underneath is also a really good read (less the whiny Agile fanboys). He has a lot of good things to say, although it does come off a little bit like “They way Google does it is really fantastic and everyone else should do it too”. And he’s right, but as many people point out in comments, Google’s business model is a statistical outlier. They don’t deliver to customers (as my current officemate put it, “their business model right now is entirely ‘build it and they will come’”), and don’t deliver products of value (that’s not to say their products aren’t valuable, it’s to say they aren’t expecting anyone to pay for them, and thus all the requisite costing and management that would normally be present isn’t there), and they have oodles of money that make it possible to do two things: hire the very best of the very best of the very best, and incentivize them to be ever more creative and competitive.

A company like that comes along once a decade or so. Observe: AT&T (1970′s), IBM (1980′s), Microsoft (1990′s), Google(2000′s). Other companies that appeared and flourished along the same timeframes were Xerox, Apple, Sun, SGI, and a few others, but I think my point still stands. There’s only one best at a time – and each time they have a unique business model with a unique offering that they deliver and maintain successfully. Every other good company have these characteristics in varying shades of grey, but there is usually only one Google.

So what are the rest of the companies to do? It seems that “Agile” methodologies help give you artificially what companies like Google cultivate naturally. Ultimately it’s all common sense. There’s some truth to Stevey’s accusation that “Agile” is mostly window dressing intended to sell seminar seats and books – but what he didn’t really acknowledge in his insightful post was what I’ve pointed out above about Google’s uniqueness.

Uncategorized

Perfect Practice makes Perfect

Even heard the phrase “practice makes perfect”? I suppose if you accept a number of assumptions and generalizations, you might consider this to be true.

Better, though, is the following phrase:

Perfect practice makes perfect

Practice doesn’t do you a lot of good if you’re practicing doing things the wrong way. If you spend 10 years playing piano with your wrists resting on the lip of the keboard, you’re not likely to be as good as someone who has spent 10 years holding their wrists up, just like Mrs. Old-Lady-The-Piano-Teacher told them to.

I think the same thing applies to experience. I’ve noticed that people assume that experience in creating software is valuable. Experience can be a valuable thing, but not neccessarily. Some people are highly experienced in creating software the wrong way. For those people, I’d say their experience is as much a hinderance as it is a help.