Doing it Quickly Takes Longer

It's an irresistible expression - we don't have time to do it properly, so just do it quickly. Leaving aside the word 'just', which I dislike, I want you to cast your mind back & think of a time when "doing it quickly" actually was quick.
In the majority of cases, it takes longer to do things quickly. That's simple history, if you go through your catalogue of past failures. In fact, given that half the time any project that is not rushed is done on or under time, it would certainly sound as if it's much more likely that a project that isn't "done quickly" will be.

This is not counter-intuitive. Here's why.

1. Pressure. The reason people want things done quickly is because there is a time pressure. If you apply pressure to something it is far more likely to explode.
2. Corner cutting/risk taking. The first thing that "doing something quickly" doesn't do is follow all of the good processes that are supposed to give a higher likelihood of success.
3. Monitoring. Everyone is under pressure, including management, to ensure that the project completes. Given the tight deadlines, everyone (at once) tries to find out what's going on so that they prove that they're on top of the problem, thus distracting those doing the work.
4. Bad estimates. Most people, if rushed for an estimate & told that a job needs to be "done quickly" will automatically underestimate it. It's a part of human nature, a part of professional pride, & it's the way such things have always been done.

I'm sure there are other things that we automatically do when someone says "do it quickly" that we wouldn't dream of doing otherwise. None of these things will improve productivity. Most will make it worse. Projects "done quickly" rarely are.

So, what do we do about it - as managers or project managers?
If you have a time constraint, then invest more resources with the expectation that no more effort will be delivered. That's a bargain where faster time needs more effort for the same output. It's a simple equation. However, I don't mean putting more people on the task, simply more people on the project. Those people have the job of ensuring that the work gets done, & nothing more.
A manager's role, for example, would be to stand guard at the developers' desks & ensure that the people who need to be informed of progress get their regular updates only from the manager, & with expectations set by the manager. Those doing the work can then get on with the task knowing that they have a schedule of reporting to only the manager once a day (or once an hour), & no more to distract them than that.
Odd bodies added to the project are there as assistants - to get coffee, collect printouts, do research, run tests, chase down experts that need to be consulted (possibly even liaise with them) - but their contribution to the deliverables is effectively zero. That's a tough call for a manager, & it's a big ask for a professional to put their ego aside & simply be at the beck & call of a peer.

That is why it is so hard to change the way that we "do things quickly". There are a lot of bad practices & ingrained habits that we have to throw away. But it will be worth it. Each time you look at how you did something quickly last time, recognise the mistakes, correct them, & get better at it - become more reliable in your "quick" tasks through creating a repeatable process for dealing with emergencies.

Top-Down on Top Again

It's a little old-fashioned, but I remember when we used to think of procedural languages as "top-down", & object-oriented languages as "bottom up". In the former, you looked at the verbs - what needs to be done - & then you broke these down into smaller units of work, etc. In the latter, you looked at the nouns - the things in the system - & modelled these to provide the basic operations that were built up to create bigger relationships.

It's a long time since I taught this ... stuff ... so I do hope we've progressed. I'm not convinced that everyone's aware of the progress, though.

I'm a keen BDD follower - every product I build follows the general principles of answering

• What does this product promise to do? 
• (what is its behaviour?)
• How is it going to be used? by whom? 
• (what is the context?)
• How does the company make maximum benefit from (justify) any given feature? 
• (what is the value proposition?)

These are very top-down questions. I don't care about the technology or even the problem that it tries to solve. The architecture of the solution, its maintainability, etc, are not a priority; that's for engineering's expertise. Performance probably is interesting - or at least the importance of performance needs to be determined.

From a project management point of view, I have other questions -

• How do I know when it's ready (enough)?
• How do I prove that it's ready enough?

This is strictly BA/QA work. No devs need be harmed in the making of these decisions.

If you look at that approach, you might think that I am a non-technical manager (product or project). I'm not. I'm a top-down developer at heart.

I believe that, even if a developer is not involved in higher levels of abstraction directly, they need to be exposed to the helicopter view, be able to provide feedback on it, & always keep it in mind with their deliverables. Without an understanding of how a release (candidate) moves the product closer to its user base or marekting's promises, there is the increasing chance of disconnect between the product that is being developed & the expectations that are being set outside of engineering.

The days of "I can prove that this software solves the problem you gave me through statistical modelling of outputs correlating to the results provided by business analysis" are in the past.

The days of "You said you wanted a user to be able to check their status anywhere" are here.

Return to Spotswood

There was once a great Australian movie called "Spotswood", about an efficiency expert sent to a small company producing automotive parts with the intention of improving efficiency & potentially laying off workers. When the expert gets to know the workers, & how their inefficient ways create a culture of camaraderie & new skills that could be of benefit to the survival of a more diversified business, he regrets the recommendations he had made on financial & professional assessments alone.

Watch the movie. Anthony Hopkins is brilliant. Russell Crowe doesn't spoil it. Toni Collette is sane.

The point I will get around to eventually is that you can't assess a team's efficiency by looking at its output alone, or its contribution to revenue. You have to also look at its potential for benefiting the company in other ways - such as their ideas & innovation potential, a feeling of well-being or loyalty that keeps staff turn-over low, or simply the store of knowledge that they represent across the business & the industry as a whole.
The object of the game is for management to recognise & harness that potential.

Over many years in the IT industry, I have seen a slow shift from a somewhat haphazard approach to managing professionals from a distance, to a tight-reined structure where the professionals manage themselves, in theory. In the former, it was easy for a clever professional with a little time on their hands to come up with crazy projects & work on them in their spare time (staying back) or in slow periods. It wasn't particularly encouraged, but there was an air of mad scientist about it.
In a modern methodology like scrum, this is less likely to happen. Pair programming means that when one person leaves for the day, the task is dropped; & there is less likelihood of having things on the back-burner, because we think in terms of getting things to "done", then moving on. Where is the opportunity to put something aside for "later"?

You could argue that that is exactly what refactoring stories & the like are for - except that they are planned in (& are usually the first to get shunted from the sprint under pressure). Therefore, the spontaneity, the creativity, etc, are somewhat dimmed or forced (refactor for four hours on the last day of the sprint). Some companies encourage their developers to contribute to open-source projects. Usually, this encouragement is carrot-&-stick: all open-source code used must be contributed to, religiously; only projects related to work are considered.

What is needed is more than a tentative understanding that a professional will, on average, use their time wisely & generate the product needed to keep the business going forward, & still have time to do "cool stuff" along the way - when they get around to it. There needs to be a formal process whereby people ask their manager something like "I want to spend half a day tweaking my widget discovery algorithm - you cool with that?" to get a languid "sure, but if you're still doing it tomorrow, you owe me some serious first-level support time".

It's a matter of trust & professionalism on the part of both the dev & their manager. It doesn't matter what the methodology is, this approach to treating people (employees) like adults, rather than machines, must benefit all.
You never know - that widget discovery algorithm might be the basis for a patent or a new product one day. Or you can just think of it as a learning experience that was much cheaper than sending someone on a course.

The Flyer

My wife asked me recently to help her make a flyer.You're wondering what this has to do with software, but by the time it was done, I felt like I'd delivered a major project, so I had to write this up as the retrospective.

She started by saying something like "I've already downloaded a program that's supposed to be good for making flyers." It wasn't. It was free. It came bundled with stuff that was useless & nigh-on counter-productive. Within the first few moments of using it, I realised that it didn't have the features I needed for the flyer, & it also didn't work well - it was poor quality. This was my first hint that this was a software project - management had decided on, & pressed, a technology that wasn't applicable for the problem at hand.

I then started a business analysis session - "What is the purpose of the product?". Her response was along the lines of "You know, it has to say ..." & she reamed off a few paragraphs of "essential features". Definitely a software project. "That's not all going to fit within the resource budget" I responded, referring to an A4 sheet.

This was going to take some true BA work.

• Who's your target user base?
• What's the product differentiater - the message?
• What's your distribution platform?
• How are you going to support the roll-out?

As usual, you have to ask the questions several times until you get a consistent answer.

Now came the first attempt to use the "proposed technology". Abject failure of the prototype. Definitely one to throw out, having learnt an important lesson.

Time to fall back on older, proven technology ... Powerpoint (or OpenOffice) may not be meant for flyers, but it works with the simplest of tweaks. No gimmicks, but solid, reliable functionality. Not only that, but I know I can turn it into PDF for distribution via email, or just print out myself.

About now, I was telling my wife to go away & leave me to it. This was a job for a professional developer, & QA wouldn't be necessary until the first release. I didn't expect this would be a multi-sprint feature epic, so I didn't feel that I had to rely on an iterative process. The product owner could easily decide that the task was done with the first release candidate. I was, however, prepared for continuous delivery - emailing her a PDF while she was wandering the house remotely with her tablet.

Tacit approval was assumed when no further issues were raised.

There was no release party, although I definitely deserved a cup of tea thereafter. I am yet to see if marketing (whose input could not be acquired in time for the initial design) can work with the deliverable as released.

Learning to Read Code

One of my junior co-workers asked me the other day for advice. They had inherited modules written by someone who'd recently left the company, & they were conflicted over whether to make drastic changes to the style & formatting, or just try harder to understand the code as it was so that the task at hand could be done.

   "How do you understand someone else's code without making it look like you're used to?"

Even if you have style guides, style checkers, automatic formatting, etc, there will be minor variations in style that can make code more in line with your own thinking, or small things that stand out as being "unreadable" that can taint the whole module. The classic examples are too much or too little comments, or too much or too little white-space. Note that these two, in particular, go both ways. It's a matter of personal preference.

No matter how much you work on Clean Code, a la Bob Martin, there will be tricks or approaches to a problem (even patterns) that you pick up in your career that are obvious to you, but will look strange & unreadable to someone else. Being aware that it might happen goes a long way to making your software more maintainable.

If you equate reading code to reading a book, for any given publishing market, the audience is essentially homogenous. As an author, you might aim for a geography & an age group (maybe a gender) or else a special interest. You more or less assume that anyone in that broad category will be able to read your book, & be able to understand what you have written - to appreciate it. The reality is that people always have favourite authors - a style or topics that they are more drawn to. Most people will also have authors that they just don't like - their style jars with them.

Reading someone else's code is exactly the same as reading a book that you didn't write. Some people write code that more people easily understand. Some write code that is targeted to a very specific niche audience - sometimes numbering one.

If you want your code to be maintainable, follow Uncle Bob's rules for Clean Code to get most of the way, but above all, remember that you are an author with an audience of coders who will read your work later.

If you want to approach other people's code to garner understanding - to maintain it - always remember that the author wasn't necessarily writing in your style, but you have to read it anyway, so look deeper for how they have gone about writing the code, how they are telling the story. The story is in there, because the code probably worked at some point. It is your job, as a maintainer, to find that story & understand it.

I can't teach you how, because I've achieved it through experience - voracious reading. There are no short-cuts to getting better at maintaining code. It just takes a lot more practice & a lot less wishing that the novel before you was as easy to comprehend as a Mills & Boone.

Technology Wars

A little while back, I started looking at a few different development languages. Each had its benefits & applications, which is why they came into existence in the first place. But, & here's what annoyed me, they each carried with them a justification that they were "superior" to any prior language, tossing about spurious claims about the limitations of some against the strengths of their favourite.

I say "spurious claims", because they sounded quite ridiculous to me, & I suspect anyone with real experience in the language under attack would agree. Sure, there is a level of comfort in the familiar, just as there is a daring excitement in taking on the new, but to then ignore these prime considerations & label one language as deficient because it can't do well a particular thing that a new language was designed specifically for, does seem to be drawing a long bow for justifying change.

Let me pick one such language, & I guarantee you'll be hard-pressed to work out which one it is:

•  It’s Perfect For Web Technologies
•  Saves Money
•  Saves Time
•  Active & Helpful Community
• Project not Handcuffed (to the original implementors)
• Build your own Plug & Play Apps
• The Big Players Use It
• You can use it too! (Personal & Professional use)

There you have it, the perfect language. Everyone should use this for web-based development. I'm sold - but which one is it? I suspect many CEOs would take this immediately, too.

This is what used to be referred to as a religious war. Once upon a time, there were only two or three great languages (religions), but now there is a proliferation. That's fine; I'm tolerant.


However, I have found the same sort of arguments creeping into other technologies within a development environment. The best revision control, continuous integration, IDE, etc.

Really - & honestly - it doesn't matter what the particular choice made is, but what matters is that you embrace that choice & follow through. You have to find the best way to use the technology at hand, become proficient, have effective processes in place that understand that technology, & continually review your processes & get feedback to learn from its use, innovate, & go forward.

I recently convinced management to standardise a team on IntelliJ to develop Java. I did this with minimal experience of IntelliJ, but with the knowledge that the team was spread across three IDEs! That was an intolerable situation that led to inefficiencies & basic time-wasting trying to get things to work in different environments, or supporting different technologies simultaneously.

Now, that team shares tips, fixes problems once (someone upgrades, tests, then gives the OK for the team to upgrade), finds plugins useful for everyone, & basically works together on the same problem from the same base level. I believe that the same could have been achieved using Eclipse or NetBeans with a similar effort - as long as it was only the one IDE.

Similarly, some complain that Jira "doesn't do what they want". That's just showing an inability to master a very simple & effective (but feature-rich) issue control system. There may be better ones, but Jira is, industry-wide, considered one of the good ones. Master the tech, don't let it master you.

Wrapping up, there are always good & bad choices for a technology, but there's usually a fine line between several good choices. At that point, put the religion aside & decide for the good of the team. Making a decision is what counts, not getting it perfect.

By the way, the "Eight reasons" was for Ruby.

Re: Productivity

I accidentally discovered Google's Go language recently. I really mean that it was an accident. As much as I like to discover these things, it's really a matter now of asking "How did this come about? Why did someone go to that much effort? What problem were they trying to solve?"

After a very short while, I had read that it was C-like, but it looked rather Python-esque. In short, it looked unintelligible, full of mystical short-hands, unstructured, arcane, & a veritable nightmare for maintainability. It's exactly what people are claiming as necessities for "better productivity".

I was aghast. How can someone be more productive when they can't fathom the code they wrote last week? How can having a faster compiler (or an interpreter) make up for the fact that you can't understand the code?

When I think of productivity, my first thought is an IDE. By that, I really mean INTEGRATED, I mean DEVELOPMENT, & I mean ENVIRONMENT. Maybe I need to elaborate. If there is a way to do everything in the one application, from design & (some) documentation to deployment & issue resolution, then it's integrated. User documentation is distinct - not a part of development - & issue tracking itself should be accessible from elsewhere (not limited to devs). There should be some consistency in accessing all of the tools that a dev uses - the databases, web servers, editors, debuggers, multiple languages, preferably across multiple environments (for a given project). That is the environment, which these days should support agile tools & methodologies like continuous integration, pairing, reviews, etc.

The IDE is what people (devs) use to be productive. Shortcuts, gestures, menu layouts, integration points, plug-ins, etc, are what makes the dev work better & smarter, without losing their train of thought or having to drop everything to do one small task with an independent app (or on a remote system).

No amount of fiddling with a programming language can ever replace familiarity with a well-set-up IDE & experience of developing in a given environment.

I started looking for comparisons of Go with other languages. I saw someone comparing the number of lines of code. Do people still do that? I can't remember counting code for quite some time - like in assembler, when you had a very small memory on board. Since then, a file of source has not had a limit, & my typing has improved. Better still, my IDE does most of the completion for me, so I don't have to worry about long names for imported features or matching my curly braces, etc. My IDE will even fix up the formatting for me later. It's that good. It's not that hard.

For those wondering, I have been an Eclipse fan for a very long time - even when it was absolute rubbish - because I believe that a real IDE is the only way to real productivity. I believe in it so much that I convinced my current VP-Eng to invest in IntelliJ so that the whole team has the consistency of environment that allows good dev technique to spread across the team.

It's at that point that I shall end this - if you're a lone wolf coder who uses EMACS, then you probably think that Go is a wonderful improvement on Visual Basic. That doesn't make it any more likely for me to hire you. If you're a professional team-player producing commercial-grade product, then you're unlikely to give whizz-bang programming languages a second thought.

The first thought is always - cool, I wonder if they came up with some new concept I could use in the real world? In this case, the answer is "no".