The Workspace Race

If you had asked me without pre-amble what I thought about open-plan offices, I would probably have answered that I had almost always worked in them. Within IT, it's very much the norm. In other office environments, it became a fashion for various reasons.

It makes sense in IT where there is a collegiate atmosphere - people collaborating on a project or related technologies, constantly in need of a few minutes interaction to verify an idea, even if they're not pairing up on the same task. There is no privacy, but the theory goes that you shouldn't need any. Open offices are great space savers, too, because you can pack more desks in.

The next step up is the good old cubicle, which gives you a sense of being cut off from the rest of the team - usually with your back turned to the place where people come along to bother you. Depending on whether it's a half-height (easily lean your elbow on the top to talk), of full (can only stick your head over the top), the cubicle walls are a barrier of mixed blessings. This is fine if you're not collaborating much, or if there are a lot of break-out spaces.

Then there's the office - a place where you can shut the door if necessary & block out everything but the fact that people keep walking past in the corridor. You can ignore knocks on the door, if you're lucky, or invite people in for an intimate chat. In IT, this is usually a great luxury.

The open plan works for IT, & it has a great history of working for different occupations down the centuries. We can easily imagine a Dickensian scene of accounting clerks tallying their numbers to a slight murmur of pages swishing & pens scratching, usually placed around the pedestal of the supervisor. We can also imagine a middle-ages scriptorium filled with monks carefully copying manuscripts with their coloured inks in precision, & the librarian available for consultation. Open plan.

I'm not suggesting that IT people are necessarily celibate or in need of constant supervision, but the idea of a space being open & littered with desks so that people share the experience while doing work that requires great concentration has a very long tradition.

I'll just throw in a bad example or two - imagine a 1950s secretarial pool with a sea of women typing up from short-hand notes at tiny desks, & the constant clatter of typewriters. Not my scene. Finally, a chicken farm, with rows on rows of confined birds doing the only task they know how (& have room for) - laying.

The modern equivalent offices are customer support & telephone sales people.

Understanding ergonomics & OH&S will not change the applicability of an office plan to its usage. There is never a "right" answer, there is just effective use of the space available. If you don't put that thought in, & review the results, & ensure that the reviews are meaningful, & act on what you've learnt, then there is always an impact. That impact is a decrease in productivity & increase in staff turn-over, usually - direct costs to the business.

Using the space for the purpose at hand is like choosing a methodology for product development. Throwing some furniture together & spreading resources about will never be enough to make a project successful. Open plan encourages open communication, but doesn't cause it. It is also true, though, that closed doors ensure that there is no communication.

The Full Story

A friend recently pointed out an article that said that presentations are slowly pulling away from buzzwords & bullet points to be more engaging by telling the full story. This means that the audience is using a much more receptive part of their brain.
I was reminded of an old cartoon (strangely, I don't think it was Dilbert) where someone plays buzzword bingo during a presentation. That's about as exciting as it gets sometimes when someone presenting is simply throwing their viewpoint at the audience to either justify their existence, or else prove how clever they are. I'm not saying that consultants are the main culprits...

This is in line with how software development has been moving from requirements that read like bullet points ("name entry field must be twenty characters") to use cases ("the user enters their name; the entry screen validates the length; the database stores it in a field") to user stories ("as a user, I want to provide my full name, so that it is stored in the system"). Well written requirements are cutting out the "translation" steps from analysis to functional specs to design, etc, causing the developers to understand how the system really works with respect to the user, & ensuring that developers & testers are working to the same end goal throughout - they're using more of their brain.

Going back to presentations as a story - if you have a mixed audience, you tend to either dumb down the bullet points to the lowest level, or else ignore that sector & pitch directly at the money men. Telling a complete story (the old-fashioned way) means weaving into context the ideas that you want to get across, & also taking non-verbal feedback from your audience (fidgeting, worried expressions) to change gears & ensure that your ideas sink in.
It used to be accepted that only ten percent of a presentation (or a university lecture) is actually remembered. Why is this acceptable? Why waste your time giving the whole presentation when you could stop at the first yawn? If you engage your audience more, then maybe twenty percent will sink in - doubling your chance of a sale/investment/interest/support.

The same goes for software development. A two-hundred page spec written by a BA that gets translated into twenty different people's implementation of functions & tests is guaranteed to fail, because there is no consistency of interpretation. You cannot make a bullet-point spec so interesting that people will want to go back & re-read the fine detail, so they'll read once, hope that they have it clear in their head, & never go back to it - ninety percent loss of information.
A user story, however, relates to one piece of behaviour in a given context, clearly stated. Once that behaviour is correct, there is no going back to re-read, there is only (automated) regression testing.

User stories & TDD (test-driven development) or else BDD (behaviour-driven dev) speak directly to the BA's audience. Of course, the best way to do this is within an environment that fosters co-operation, so I do mean an agile methodology.

Hereafter, the person telling the story is not an external consultant proving how clever they are, but a part of the team who all want to know what the full story is.

Curves Ahead

When you're driving at speed & you see a sign that says something like "Curves Ahead", it's a good time to slow down.

When you're on the bleeding edge of technology & you're ahead of the curve, the trick is to maintain speed, hang on tight, & ride it out.

In a way, the same thing is generally at stake - your future. Drive too fast & you won't have one. Make a wrong technology choice & you won't have one. The difference is that very few people drive in a competitive market.

Getting ahead of the adoption curve is very risky, & it doesn't always pay off. There are often choices that get made way back in the journey that don't let you change the technology route. If you're developing for the iPhone/iPad platform, the question is not if you'll support the recent iOS release, but how soon you can - how fast you'll take the curve - because the customer base is ahead of you.

But there are some choices that can wait - like supporting new standards before they're implemented. It's great to have a tinker with Java8, but try to incorporate it into your IDE, let alone hoping it will work reliably in beta. What about HTML5 & CSS3. Everyone seems to want to develop ahead of the curve, but in this case the customer base isn't really there yet because browsers aren't fully compliant & users are notoriously bad at upgrading their browser anyway.

Being in a beta program is a great way to look around the curve & influence the landscape ahead, but you don't want to drive around a blind corner to discover that the road hasn't been built yet. I remember Bullant Technology, & how it was going to revolutionise the web with high-speed transactions. Whole companies drove off that cliff.

Professional drivers use their experience & develop techniques to stay on track & stay alive. Professional technologists rely more on luck & gut instinct to live by the choices they make. If they fail, they move on to another race. Can we measure the success of a technology driver? Can we see how the championship points table stands?
At least that sounds easier than looking at the manufacturers' points table - they tinker with the technology vehicle so often it's hard to tell what's being driven at the front of the race.

Abusive Language

Sorry to disappoint, but this is actually about Java8.

A long time ago, I was an academic, & we used to teach object-oriented programming in C++. How naive! This was when Java was a mere pup, so it wasn't really an option. The important thing was teaching object-oriented-ness (in theory) & then showing the students how to use it in practice.

Years later, I went from being a C++ developer to being a Java developer - during the war. No, I don't mean a military conflict, but the point when those two languages had some commercial altercations. Propaganda leaflets were dropped from skyscrapers with strident calls for "Multiple inheritance!", etc. There was a lot of discussion over maintainability, libraries, the friendliness of the language (readability), the viciousness (the ability to write bad code), etc. In the end, Java "won out" because it was more web-oriented, & then a lot of the C++ world turned to C#.

A few years ago, I was introduced to Scala. Without delving into it commercially, I could see that it had become an academic favourite because it was a way to do functional programming - which represents theoretical ideals - & it also runs on the JVM, which makes it Java friendly & more useful than Haskell. At the time, I thought "nice theory". I couldn't see how functional was going to take the commercial programming world by storm, or how a new language would fit in. Who wants it?

Now I've got my dev copy of Java 8. Each of the previous major upgrades has been an improvement - some in efficiency of the JVM, some in better coding style. Up until now, though, the introduction of generics, which was effectively C++ templates a long time overdue - was the biggest change to the way Java is used. Some would say that annotations were as big a change, but this depends on whether you take advantage of frameworks (Spring, Junit, ...).
Java 8 has Lambdas.

Although you might think that anonymous classes & defining callback interfaces had already covered this area, it was messy, so you avoided it. Now, there is encouragement to be functional. It will be easier to write functional code within object-oriented Java. You will discover that you'd been doing it quite a bit before (in event handlers) & can do it better & more often.

Here's the kicker, along with the new way of writing lambdas (which is VERY concise) come other short-cuts influenced by Scala & Ruby that do seem to take away some of the elegance of Java - where verbosity was often a blessing. I can recall, during the war, how we were told to avoid inline-conditionals, on the basis that they made code unreadable. Now we have inline functions.

Is there a driver for making things easier or quicker to type? I thought that's why we used IDEs with short-cuts. Good code design & development can be partially auto-generated from UML (theoretically), then the features defined in TDD before the implementation is begun. XP's mantra of pair programming is distinctly on the side of "think before you type".

There has to be some balance between introducing new language features that work elsewhere (lambdas, generics, annotations) & staying true to how that language is used professionally (readability, testability, design).

In the world of written & spoken languages, some countries have committees that ensure the "purity" of the culture represented by the language. In Java, we have Oracle & OpenJDK. At some point, you have to ask whether new concepts need to be incorporated into the culture, or whether they would just be an abuse of the language.