Today’s lesson is mainly for the people who want to use the Talia source code, but it could be useful for many git users, so I’m putting it here. In our code we use git submodules a lot; they are a bit like the good old svn externals but have different quirks that are not that easy to understand. And of course neither the official documentation nor the tutorial explain it in more detail. (I’ll assume that you’re already familiar with the general concept):
In my quest for the perfect project management tool, I tested out Mingle (if you want to see all those features, just browse their site).
It’s a really flexible tool and with the new version it’s really getting close to what we’d need. They got some fresh ideas, a flexible tool and lots of eye-candy. It was even easy to set up. I’d try it for real, if it weren’t for those few big gripes…
For the last two posts, a spend half the day researching Ruby weirdness instead, quite “unproductively” instead of hacking in a solution for my original problem.
After posting the two entries, I went back to my code, and was able to make the unit tests pass by just deleting four characters…
I haven’t changed my mind about software development being an engineering task.
However, after reading posts like this one, I think I’m starting to get the idea of what bugged the other guys.
Here’s the catch: Software development is not manufacturing.
Manufacturing is about creating lots and lots of copies of the same thing, using some blueprint and a predefined process.
Software development and other engineering disciplines are very different: They’re about making the blueprints. Software is special in that the “blueprints” are the actual product. There’s no manufacturing involved. Never ever.
It doesn’t make sense to talk about software development in terms of manufacturing. And software processes which build on manufacturing processes are bound to fail. Once you think about it, that’s pretty obvious.
A few days ago I was browsing through Jeff Atwoods “Coding Horror” again. And this time he missed the point in a very profound way. To be fair, he falls for an all too common misconception: The belief that software engineering is very special and unlike every other kind of engineering.
Since the misconception is so common, he’s easily able to back it up by quotes from some Sam Guckenheimer of Addison-Wesley fame. But that doesn’t make it any more true.
The simple fact is that software engineering is very much like other engineering disciplines. There’s nothing inherently special about it.
Time management is tricky. Or isn’t it? At least it seems that a lot of people are having problems with managing their time (see Sonja’s post from one year ago).
The dirty little secret is: Time is limited. You have 24 hours each day, and you can’t just go down to the corner shop and buy some more. People seem to believe that there is some ingenious “time management” scheme which allows you to do more stuff, but there isn’t. You can’t do more stuff, because your time is limited.
I just dug up some pointers to articles on hungarian notation. The
catch seems to be that what is commonly known as “hungarian notation”
(and which I have to use at work) is not at all what the original
author intended it to be.
Developers don’t like schedules. Sure, everybody agrees that they are a good thing, theoretically. There are loads of advice on how to do them. Still nobody likes making them, or using them. It seems that making schedules is like taking the rubbish out. Or worse.
One of the reasons is that a honest schedule can destroy your self-image.
Using common base classes is one of the most valuable things that object oriented programming contributes to modern software development. Whenever you share a common base class within two implementations, it saves you from developing the same code twice and speeds up your development. It keeps your program code small and helps to reduce maintainance effords.
So you may come to the conclusion that it might be a good idea to split up the solution for your current problem into a generic base class and a specific class, which inherits from this generic base class. And cause you are a real cool programmer, you write the generic class so that it not only solves your current problem, but a superset of it, so that others can use it to solve their problems too.