The Bad Time

Well.  I’m nearly five (I’m secretly waiting until I can start quoting A.A.Milne!) but the inevitable has finally happened.  My workplace is going through some “structural changes”, shall we say.  For the first time in my career, people I know and respect are losing their jobs around me.  I don’t want to go into my opinions of the specifics of the decision as I don’t have the full picture.  I certainly don’t have the whole set of numbers nor the strategic view.  But rather, I want to go into the emotional side of things.  Because actually, it’s quite a scary time for everyone involved.

Many people have been saying that the writing has been on the wall for a long time.  Certainly the sales data sent through on the internal financial reports haven’t been painting a rosy picture at all.  Given that this is my first time experiencing this level of staff redundancies, and ones so close to home, I can’t say with any kind of truthfulness, that I saw this coming.  I honestly believed that we would weather the storm and that because we are bidding for several large contracts at the moment, that we’d all be breathing a big sigh of relief sooner, rather than later, that we’d be in good shape again.  Apparently not.

Read more of this post

Big Up Front Design Considered Scary Beyond All Belief

I had never before been able to put into words why I really hated it when a senior developer (Mr X) I worked with demanded I had a Big Up Front Design before I wrote any code, but I knew it irritated me to the core.  Because Documentation is a Good Thing™ right? Except that I am now trying to work alongside someone on a particular project (whom I shall call Mr Y), who is still under the influence of said senior developer.  I’m trying to help Mr Y  to produce a design which will satisfy Mr X so someone can eventually get around to the task of implementing the thing.

I’m not saying all design is bad, far from it!  I just think that most capable developers are really creative people who like to battle with the machine.  They are, in my humble opinion, considered capable because they’re constantly analysing their design and making tiny adjustments where necessary.  Even tiny things like changing that function parameter to be “const” because we’re not modifying it is almost entirely what I would call design.  The function would do the same job without that modifier, but now the signature more eloquently describes its intentions.  So what I’m really saying is that I don’t think design and implementation are separate activities.  This shouldn’t be revolutionary at all, but evidently from what I’m now observing, clearly there are some people who still believe it to be true.  Based on this thinking, I thought I was going to coin a new term: “Continuous Design”, but a quick google showed me there’s already a wikipedia page.  I guess I can’t add myself as a citation now!

Read more of this post

Software As A Team Sport

Right now, I’ve found myself in a contrast.  I am working on Software, alone.  Sort of.

I’ve previously remarked in passing my firm belief that Software is a Team Sport. And I have set out with the intention to directly contradict myself by successfully conducting a software project by myself. Sort of.

It’s a natural and reasonable question as to why I keep backing away from the notion of solitary work. I’m doing this for two reasons. Firstly, because the code I’m working on was written by a great multitude of people over the years and no single person can understand the whole lot. And because there is an entire team who is technically available to answer my questions. Except for the fact that they’re half a world and an extremely inconvenient time difference away. So while, due to the former reason, I have been asking questions of various people in parts of the code I don’t yet understand, the latter means I have been quite reticent to do so and have in fact spent at least an entire day trying to figure out an answer I was provided in roughly 10-20 mins on the other end, because I had to wait that whole day before my email was answered, anyway.

Read more of this post

Communication is half-duplex

Communication.  It’s something that we technical folk are traditionally un-awesome at. Sure, we can do things like read Strunk and White to make our blog-writing better, which fits nicely into our world view. Those two guys have provided a succinct set of technical rules, with examples and counter examples, on how to write well england. Which is great. The least effective method for communication is now a solved problem. Hurray. Blogs, however are clearly a better method for communicating things, well ok, slightly better – because they at least have a comments section where, given enough eyeballs, all misunderstandings become shallow. Or you eventually get to arguing about Why Hitler Was Bad.

So why is Documentation hallowed as so necessary and important, if reading it (often far removed in time, space or both from the original author) is such a terrible way to gain understanding? Sometimes I read documentation. But mostly I only read a small portion of it. In almost all circumstances, I’ll go and talk to an actual person who I know to have been in that portion of the code. The document I have referenced most in the current company I work for is the definition of a protocol. Not a design document. Not a UML diagram suggesting the structure of the code base. A protocol. And I look at that the most because I periodically have to pick apart a stream of it to figure out where a bug is hiding.

Read more of this post