Author: Piet

Software developer asking his boss why it takes ages to receive feedback

The Cost of Waiting for Feedback in Software Development

October 3, 2019 / Piet / 2 Comments

[In the series ‘Explain this to me like I’m a manager’]

Let’s imagine you are paid to write emails.

The company you work for has a policy that all public emails from an executive should be written by someone with a clear head and proper training. That someone is you.

It works like this:

You receive an in-person briefing from the executive of what the email is about.
You go back to your office to work on the email. In case a question arises, you phone the executive and usually get an answer right away.
When finished, you present your email and edit it together until you’re both satisfied with the result.

The whole process takes about half an hour up to several hours.
This seems OK. It might even be kind of fun, right?

Now, imagine a different way of working

The only difference is that you’re not sure when you’ll get feedback or approval. It might be right away, or it might take several weeks.

Since you don’t know how long it’ll take, you start working on the next task. Instead of having 1 email “in progress,” you might have 20, 30 or a whole lot more.

This the exact same job, with the same input, but it seems much more cumbersome and a lot less fun, or not?

Well, unfortunately, this is the way most developers are working

In this example, we’re assuming there is no middleman (PM, analyst…) through whom all communication passes, introducing his or her own ideas, obfuscating the message in the process.

As a developer, I have often found it very frustrating when it takes ages to get feedback or answers.

You start working on something. You get stuck, you need feedback. Because you don’t know when you’ll get answers, you put the task on hold and start working on the next one.

But wait, the client has the exact same frustration!

Yes, I’ve been there: for several years, I worked on the other side, steering contractors/freelancers to develop custom software for our organization.

It is just as annoying to give extensive feedback to a developer, only to get additional questions 2 weeks later. These questions are usually ones that could have easily been answered if asked right away, but 2 weeks later, I can hardly remember what it was all about!

Surely, there are better ways to waste my time!

What is the engineer’s solution?

Let’s use a tool to manage all this “work in progress”, with statuses, flags, due dates, source integration, custom fields, assigned persons, reports, milestones and all that jazz.

This is an often unnecessary over-complication that is regarded as standard practice.

“That’s how it’s done!”

There are indeed situations that demand this way of working.

But, most of the software projects out there are actually quite straightforward and don’t benefit from these “solutions.”

The root cause is still there: it takes too long to receive feedback. As humans, we can’t temporarily store our built-up understanding—our “grasp”—somewhere until we need it again.

So, what’s the alternative?

We are all busy and we can’t just drop what we’re working on whenever someone demands our attention. But what if we could?

What if we could work on 2-3 tasks at the same time?
What if we didn’t need tools (except for a basic to-do list) to manage the progress of all our tasks?
What if we could work intensely with the client on a few tasks from beginning to end? And not start a new task until these were actually completely finished?

Why am I asking these questions? Because it would save time, money and frustration!

This is one of the core elements of several task/project management frameworks that suggest focusing on a limited number of tasks during so-called “sprints,” or that impose a limit on the “work in progress” (a WIP limit).

Often advocated. Seldom practiced.

And really, no one is asking you to drop everything at every question; just don’t let things slide forever.

Do we really waste that much time waiting for feedback?

There was a study, conducted at Palm in California, the makers of the first PDAs. This study measured how much longer it takes a developer to fix a bug detected 3 weeks later instead of on the same day.

Now, how much longer do you think it takes?

About twenty-four times as much, no matter if the task is big or small.

Did you also fall off your chair? My initial guess was 5-10 times, which should be enough to inspire anyone to give this some additional thought.

But waiting endlessly for feedback isn’t the only cause of WIP explosion!

It’s also:

The delay between analysis and development
The delay between development and testing (if you use testers)
The delay between a developer reading the tester’s feedback and acting upon it
Waiting for approval or a sign-off on something
…

Now, how do we fix this?

Well, it’s not that hard… to write about! 🙂

Here are my suggestions, which should work no matter what role you’re in:

Try to get everyone on board. Send them the link to this article. Or send them this excerpt from The Scrum Book; the author is just a bit more known than me, so it might work better! 😉
Lead by example: give feedback and answer questions on the same day or at least within 24 hours.
Explicitly state that you try to give feedback asap. Actively request the same from everyone you work with, including clients and managers. Follow up if necessary. A lot of people let things slide until they notice you’re consistently following up.

And, if your role allows:

Try to get everyone (necessary/needed) working on roughly the same task(s) at the same time.
Try to limit the number of tasks and the “work in progress.” Impose a WIP limit.
Cut the number of in-between-persons. They often serve no real purpose, except to consolidate or translate information. Developers often communicate too technically. I still make this mistake myself. But I also believe you can learn to communicate on a more non-tech human level. Listen to what is really being said, and try to respond at the same level using the same words.

I think it’s always better to have direct communication lines because it improves the possibility of learning from each other.

But I’m a developer. I can’t just demand my client’s attention!

You’re not demanding immediate attention; you’re asking not to wait for ages to get a reply.

I know this is not the standard way of working for a lot of developers: being proactive instead of reactive, reaching out instead of tackling that next user story or bug. I don’t mean to be condescending. I speak from my own practice, from the mistakes I’ve made, from experiences with failed as well as successful projects.

This might be one step (of many) to becoming a “10x engineer” and to show that you’re on top of things and care about the project.

Remember, all those non-tech people you’re working with really don’t know much about software development.

There’s nothing wrong with steering and educating them on how to optimize the process and save time and money. Who could be against that? (Unless, of course, your time is billed by the hour 😉

… And what if you get feedback from multiple sources, contradicting each other, even contradicting your own opinion?

Tackling “Design by Committee” is another story. Sign up here and stay informed.

Follow @PHadermann

This image shows Nessie, Bigfoot and a 10X engineer and asks if they are 'fact or fiction'

Those are not 10x engineers you’re talking about

August 22, 2019 / Piet / 0 Comments

There’s been a lot of discussion on Twitter recently about so-called 10X engineers. Here’s the tweet that started it all:

I thought it was a joke but this guy is serious. Basically you know the engineers you hate working with? They’re being praised as vital to a team: https://t.co/d8yEaLHZtW
— Joe McCallister (@Joe_McCallister) July 14, 2019

Just to make sure you’re on the same page: a 10x engineer supposedly provides extraordinary value to their team and organization.

Now, this has resulted in dozens of jokes, memes, people wondering if these engineers also incur 10x technical debt and so on.

The general idea is, you don’t want to work with someone like that.

On the debate about 10<xEngineers, I think Reed Hastings said it well#10xEngineer pic.twitter.com/lrEny3crAK
— Subbu Palaniappan (@subbupl) July 14, 2019

But these are not 10x engineers.

These are exactly as described: toxic jerks. And there’s a huge difference between the two of them.

Sure, toxic jerks might self-promote their way to being perceived as a 10x engineer, but I doubt they will ever provide 10x value to their team or organization.

In what kind of organization would that behavior ever provide a 10x value? What kind of organization even enables such people to thrive? (Politics, maybe? ;-))

I do understand that if you’ve never worked with a 10x engineer, or if you believe they don’t exist, you may mistake this person as one.

And yes, I’ve worked with these toxic jerks and of course, I agree that you want to avoid them. They can provide value in some edge cases, but I’d rather not have them around.

Fortunately, I’ve also worked with what I regard as true 10x engineers.

And I’m not the only one.

They build up a strong team around them so that everyone feels like they can work in the codebase. They see opportunities and fit them to the right teammate who needs it.
— Jammie (@jaymaymo) July 13, 2019

(show full thread)

Whether they provide “10x” value is another discussion. Let’s assume for now that they are very valuable to their team and organization.

And how do they do that? Well, these engineers have a combination of the following traits:

Better-than-average tech skills and knowledge in a wide area. (OK, this one was obvious.)
Eager to improve how they work and how the team works.
Assisting other people, taking new people under their wings.
Giving credit where credit is due.
Good communicators, good listeners.
Not too cocky to change their mind or admit they were wrong.
Eager to learn, on a wide area of topics.
Accumulating domain knowledge, if active in a specific field.
Dedicated to their job and everything related.
Emphatic; trying to understand the customer, colleagues, their manager, …
Last but not least: ideas of 10X value (or way more), because of a combination of the above!

This is by no means a complete list; it only contains what I remember from the “10x” people I’ve worked with. Just to be honest, none of them possess all those traits and some can be a bit of a jerk from time to time but never in a major toxic way. Like most of us, right?

Note: there are a lot of soft skills in this list, but they are still engineers, and their excellent tech skills remain their biggest asset.

The 10x value isn’t all originating from the engineer, though.

The culture of the organization and the environment they’re working in play a major role too.

Can they work uninterrupted if necessary?
Do you promote a culture of helping and sharing?
Do you facilitate good documentation, provide the necessary tools and training?
Do you often reflect on your way of working (a so-called retrospective)?
Is there a constructive, no-blame culture?

Going from a noisy open-plan office to having a couple of distraction-free hours a day might already “2x” your entire team. Unfortunately, I’ve seldom met a non-tech manager who believes strongly enough to actually take action.

You know, those engineers you see with their headphones on? It’s not because they like music so much; it’s because the music is less distracting than the office noise.

Bossy guy complaining to someone else: "They can't be that busy, they're all listening to music". There is also an "engineer" working concentrated in front of his 3 monitors, wearing headphones.

Now, how do you recognize these 10x engineers?

Well, in my experience, the direct colleagues and managers know, but the rest of the organization usually doesn’t.

It has taken me weeks or even months to realize a person I’ve been working with belongs in this category. It’s not that they fly under the radar or keep a low profile, but self-promotion isn’t on top of their list. It’s also possible I’m a bit slow at recognizing such things.

Sometimes, I have suspected people to be 10x much sooner… in a matter of days or even hours. But these have almost always turned out to be self-promoters of the toxic jerk variety.

So no, there are no rules or tricks. It’s the same as finding out if you like working or living with someone. Maybe you’ve got a gut-feeling, but it will take some time and going through tough and stressful situations together before you know for sure.

Would it be possible to nurture engineers to 10x level?

Well, I’m sure you can, up to a certain level and with proper coaching.

What I’d do is provide a “10x nest” with an optimal culture and environment to attract, nurture and retain 10x engineers.

Yes, I know that sounds mushy, but there’s a shortage of good engineers. Instead of hiring additional ones, what if you tried to optimize for the ones you’ve got?

Providing a good environment and culture might attract more talent if needed, as 10x engineers often have other 10x engineers among their friends. Birds of a feather flock together, so why not let them flock to your 10x nest?

But be careful that you don’t end up with a toxic clique!

Have you worked with 10x engineers?
Or do you only know toxic jerks impersonating as such?
Don’t hesitate to reach out on Twitter or by email!

Recognising a Bad User Interface at First Glance

July 3, 2015 / Piet / 25 Comments

This article trended on Y Combinator’s Hacker News where it generated an elaborate discussion.
It was also voted the Best “Everything Else” Article of July 2015 on CodeProject.
And translated to Japanese (with my approval).

When I wrote my previous blog post, it dawned on me that a trained eye can often spot unfriendly software a mile away.

It’s just like forming and making a first impression when you meet someone new. Apparently, this takes about one-tenth of a second.

Unlike judging a person though, judging a user interface isn’t part of our instinct… yet. But within just a couple of minutes, and often much faster, it’s possible to get a pretty good impression of whether the user interface was thought about or rather just an afterthought.

As I wasn’t sure of how this happened, or which warning signs were actually firing, I started to pay attention and take notes.

Here are my findings…

Too generic or inconsistent use of terms/labels

These aren’t the user’s words, but rather ones the programmer comes up with.

I trialled event organizing software the other day. The visitor/attendee was sometimes called ‘user’, which confused the hell out of me (you could also add additional users/logins that weren’t visitors).

At the company I work for, we once prototyped a new wizard-like process. It consisted of several screens that used 3 different words to depict the same person: the trucker, the cardholder, and the starter (needless to say this was corrected before going into production… and why does this reminds me of The good, the Bad and the Ugly?).

When you know how the process works, you won’t really notice this. But when you’re confronted with this software for the first time, you might wonder whether they’re talking about the same person, or different persons in separate roles, or… who knows?

You don’t want to confuse your users. Hallway testing helps here.

An Excel/development IDE – like user interface

If you ask an inexperienced non-tech person to design a user interface, it often looks like it was designed in Excel. Excel is the most unconstrained application most people know, and a lot of software starts out as an Excel sheet before growing up into ‘real’ software.

On the other hand, developers have a knack of seeing everything as the user interface they’re most familiar with: their development IDE.

Use of image-only icons/buttons that have no distinctive meaning

Stock icon images seem suited when you already know what they represent, but when you see them for the first time you often don’t have a clue.

Unless it’s absolutely necessary, use words instead of icons… even though icons look better.

Unclear/confusing error messages

(written by the programmer).

Test this by entering an incorrect value in a field or leaving a required field empty.

Do you immediately know where the error is (even without having read the error text), or do you get a generic ‘fill in all required fields’ or ‘this is not a correct value’ error?

Even worse is some database error text. Or no error at all, resulting in a record that wasn’t saved without you knowing it.

Too much text/instructions

‘If you are an X, then you have to fill in Y and Z. If you are not an X, please only fill in Z, unless Z=1, then you should fill Y too.’

I don’t know how this is in other countries, but in Belgium it feels like you’re filing your income tax.

This is typical of programmers being ‘smart’ by avoiding some extra steps/code… and shouldn’t get past QA. Things like this will not only cost you customers, but will also cause a lot of unnecessary service-desk requests.

A long time ago (the previous century actually) I developed EDI software, based on ‘Message Implementation Guides’ (MIG) that contained constructions like these. And instead of thinking about making this more transparent, we just gave the user a number of fields and the MIG’s instructions on which fields should be filled in which case. That was the way it was done, and we didn’t give it a second thought at that time. Thank god for the ability to learn from mistakes.

Excerpt from an EDI Message Implementation Guide

I’ve even seen this taken one step further into absurdistan when someone thought it was clever to ‘implement’ 2 different messages (data structures) that had some similarities in 1 set of forms.

The time this saves the developer never weighs up to the users getting confused and calling support.

Weird, irrelevant and complex date/time formatting

For example: ‘2015-06-29 15:44:21 EST’, which is probably the default, unformatted output of whatever language/framework the software was programmed in.

15:44 might suffice, or Jun-29 15:44 (which makes sense to European AND US users).

In some cases it can be better to have a more human, relative notation, e.g. ‘within the last hour’, ‘yesterday’, ‘next week’…

Being too Mouse-dependent

No logical tab ordering, no keyboard shortcuts: the need to do everything with the mouse.

This has been annoying users since the invention of the mouse.

Too many pointless message boxes

‘Are you sure you want to print the document?’

Then showing the print dialog where you can still cancel the printing process.

And just how bad is it to print something by accident that it needs your permission in the first place?

Inconsistent warning dialogs

A while ago I saw a CRM-ish application.

When exiting an unsaved contact’s form, it said
‘Are you sure you wish to exit without saving?’

When exiting an unsaved company’s form, it said
‘Save changes before exiting?’

Clicking ‘yes’ obviously gives two different results here.

The user interface is totally empty when starting out

When seeing a ‘clean’ installation or account, there are no instructions to get you started.

You should guide your users towards taking their first steps here.

“You don’t have any contacts yet. Click ‘add contact’ to add your first contact.”
“We see that you’re new. If you want a short tutorial click here.”

You get the picture.

Visual clutter

Unneeded use of separating lines, grouping boxes,.. less of these = easier on the eye. It’s much better to group things together by position than by placing them in the same box.

Do you know more immediate clues that you’re dealing with a lousy user interface?
Tell us in the comments!

Being User Friendly Beyond the Software

A company I once worked with had such long emails that users used to phone to ask, “You just sent me an email… could you please explain what’s in it?”

It was also common that when someone called with a question that wasn’t in the email, the email template was changed to include the answer. That seems the right, logical thing to do, no?

Unless the emails become so long that no one bothers reading them anymore.

Also, when customers called, the support team explained things with the terms they were seeing from the internal software – “I’m sorry sir, your validation is still ‘unverified’.” Unfortunately, in most cases, it meant absolutely nothing to the customer, they didn’t know what their ‘validation’ was and why it was ‘unverified’. And you could see the support people get annoyed because they had to explain this same thing over and over to the ‘stupid users’.

Making your user interface more friendly is an iterative process. The support requests should be regularly checked for recurrent issues so they can be fixed/clarified.

Agree or not? Do you know more immediate signs of a bad user interface?
Tell us in the comments!

Header photo by rdolishny, used under CC BY-NC 2.0

Enterprise Software Acquisition: What’s Missing and How to Fix It

June 18, 2015 / Piet / 3 Comments

Enterprise software isn’t user friendly. It’s often so bad that it costs you time and money, on top of an already hefty price tag.

Sure, ‘user friendly’ is one of the requirements, but no salesman will admit that their software isn’t. And you often can’t really put it through a ‘trial’ in advance, because it takes installation, configuration, training, customization, blah blah blah.

And why does it need so much configuration? Because not only do you have a huge list of requirements (lots of them irrelevant and unnecessary), but the other clients had their specific requirements too, and a consultant needs to ‘program’ the configuration to make it work according to yours.

The good thing is that they’ll throw in some unneeded features for free. This makes the software even more of a jungle to manoeuvre, but hey, no problem, surely they’ll arrange some training for you. And if that doesn’t work, just contact their outsourced support and talk to someone who doesn’t understand half of what you’re saying and vice versa.

Yes, this sounds a cynical, but it’s all true, Dilbert said so!

Hallway testing to the rescue!

“A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.”

Joel Spolsky, The Joel Test – 12 Steps to Better Code

It takes some guts to ask and explain, and people often (virtually always) find it weird. But in my experience, it’s the single best thing you can do to make your software better. (Actually, I’ve got some tips to take the edge off the experience, but that’s out of scope right now.)

So, that’s my proposition: Maybe the vendor can’t provide a ‘real’ trial installation, but surely they have an installation somewhere (what the developer is testing on if necessary) where you can have some of the future users perform basic tasks, and see how far they get without training/asking for help.

And if the vendor can’t facilitate these tests, it means they don’t even have a way to demo or test the software themselves. This is such a huge red flag that you should just forget about them. And if it’s not, they’re lying and errrm… you should just forget about them

Hallway testing has proven invaluable to me when trying to produce user-friendly software. It can also be applied to test third party software before committing.

By the way, “Don’t Make Me Think” by Steve Krug is a very entertaining, short and to-the-point book that you can read in one sitting and will benefit everyone somehow involved in developing (or acquiring) software. If you’ve read this far, it’s very likely that you will benefit from reading it.

Isn’t Hallway Testing only for occasional processes?

I know some might argue that hallway testing is only good for less used software/processes where no training is wanted.

Like a shopping cart checkout process, requesting a day off, or booking an appointment at the doctor’s office.

Some software might have a steep learning curve that pays off by saving you time later on. This software isn’t suited for hallway testing.

It’s still possible for a user interface to cater to new as well as experienced users. You should also be able to accomplish the core tasks in an intuitive way without having to jump through hoops.

Think about how much smoother user on-boarding would go if the software were easy to slide into from day one.

Some example Hallway Testing tasks

Let’s say you’re evaluating a CRM system — I think it would be safe to assume that a new user should be able to do the following:

add a contact
search for this contact
change the contact

And when evaluating a bookkeeping/invoicing system:

add a client
make an invoice for this new client
send the invoice through email

If you need training or a manual for such basic tasks, it’s safe to assume that there’s something wrong with the user interface. Don’t you agree?

Other things to keep in mind

Modern software should be able to talk to other software

Does it provide some kind of API (preferably a web service) to communicate with other software?

This is often overlooked.

If possible, get a programmer to take a look at the API: how difficult and complete is it? This doesn’t have to take long, you can get a good enough impression in about an hour tops.

A while ago I was exploring the possibility to have some of our software talk to one of our partner’s systems. This supposedly required custom development from the vendor, as there was no way to interface with this recently purchased software.
And this in 2015.

Another vendor I talked to had an API but no documentation :-/

Responsiveness is a requirement

Responsiveness is just as hard to define as ‘user friendly’, but just as important. It’s absolutely crazy that a human has to wait ‘while the computer is thinking.’ Still, how often does it happen?

Slow, unresponsive software costs not only time, but also a lot of frustration. We all know, but too often ignore this. We often also don’t seem to have a choice but to live with it.

What about including these requirements:

The user should never have to wait for more than 2 seconds, except when generating a report or performing a search.
Report generation/searches should be able to run in the background.
95% of the user’s actions should give a response in less than 1 second.

Yes, these might be hard to measure, and they might be a bit strict… but it should open the conversation to what is feasible, and what is and isn’t acceptable for the users. Let that salesman sweat a bit!

I’ve seen a very responsive, snappy system grind to a halt when coping with a standard load. This could only be solved by throwing more and faster servers at the problem.

Later on, rather by accident, someone discovered the database had been totally misconfigured. If the ‘expert’ investigating the original issue had been a bit more competent, this would have saved a shitload of money. But alas.

Did you hunt on google for alternatives?

There are lots of SAAS providers for the craziest things. They often don’t come with a month-long sales process, a salesman that’ll have lunches with you, consultants to configure everything and trainers to get your users going.

They also lack the hefty price tag and often have a trial version you can try for free.

This software is often user friendly by default. It has to be — it needs to sell itself.

They might not meet some of your requirements or customize to your specs. But are all your requirements really necessary or rather nice-to-haves?

Lots of businesses don’t know how to find these, and there’s no salesman interested in a commission on a $149/month SAAS, or no consultants to assist you with the purchasing process.

Just search for ‘<your software> vs’ in google, and behold: a list of alternatives!

Of course, you could also search for ‘<your software> alternatives’, or ‘<your software> alternatives free trial’.

But I don’t want the data to leave the company!

Okay, there might be a bit of a stigma here because your data is stored in an external environment. How valid that is… that’s for you to decide. Just remember that lots of ‘Enterprise Software’ already has SAAS and thus the data isn’t stored on your own servers.

And in case this wasn’t clear: that’s usually an advantage. No servers to buy, maintain, backup and upgrade.

Also remember that all email interaction with your customers passes through the big bad outside world.

And your own servers might not even be installed in your own data center, or you might be planning on migrating them ‘to the cloud’ in the future. And then what’s the point of being paranoid about an SAAS storing your data?

Reconsider having it custom developed

…depending on the situation of course. Usually easier said than done. Sometimes not.

If I hear about the total cost of some software, and then see what a jungle it is to navigate, and how few features are actually used, I often think it would cost a fraction to get it custom developed — usually not the whole offering, but just the features that are actually used.

There are exceptions, and there’s rarely a gray zone. Considering my background in software development, I might be biased.

Don’t blindly believe references

“XXX and YYY are using it too”
“If it’s good enough for ZZZ, surely it’s good enough for us”

You wouldn’t believe how often I’ve heard these as the decisive factor, when they’re far less relevant than the need for a user-friendly interface.

I think references are often used as shortcuts for proper due diligence.

References are a basic sales technique. References of well-known organizations are priceless. Keep in mind that these might have had a far better proposition than you, just to get them on board. I’ve done this myself. A product/service without references is so much harder to sell.

You can ask for an actual person to contact at these companies (not sure if this is common practice, but does that matter?). It’s usually the decision-maker though, or at least someone who will only say positive things. Someone who won’t tell you they made a bad decision, or just doesn’t know because they don’t use the software and no one dares to tell them it sucks.

Unless they’re really, really dissatisfied. I had this happen recently. My conclusion was that the vendor didn’t have any happy customers at that time and thus hoped that dropping the reference’s well-known name would suffice… that I wouldn’t actually contact them.

To get a more objective view: try to find someone unconnected at that company (check LinkedIn) and ask for their inside scoop. I have done this on occasion, and gotten valuable info (assuming my source was trustworthy).

Remember: Always take references with a grain of salt!

Look online for actual user’s reactions

But remember that very popular software will always have people who don’t like it, and also competitors spreading FUD.

Had a good read? Sign up here to get notified of future enjoyable, insightful and (dis)informative posts!

Comments? More tips? Frustrations? Dirty jokes? Leave them below!

Everyone uses Java/C# and Oracle, why choose something else?

May 18, 2015 / Piet / 0 Comments

If the tech guy (or girl) advises going for a less common technology, and something goes wrong, he’ll get blamed. “Why didn’t you use Java/Oracle/IBM like everyone else does?”

And you can be sure that something WILL go wrong sooner or later… and this guy knows it.

He knows he has a mortgage, kids that have to go through college, a wife with a spending habit… why take any chances? What’s in it for him if it works out? And what if it doesn’t?

People avoid taking risks. Especially people who work a ‘safe’ job as an employee.

Is this the lizard brain at work?

For the record: There’s nothing wrong with Java/C# (or any other language for that matter). They all have their (dis)advantages on speed, memory usage, developer-friendliness, license/price…

Yet NONE of them fit all tasks and situations you can throw at them, while yes: you can use most of them to implement most tasks.

Do you have any idea how many programming languages exist?

Just look at this list. These languages weren’t developed because there’s hardly any difference between them, or because a ‘one size fits all’ language exists.

Now, if you are a developer/sysadmin, I probably needn’t explain. But as I’m hoping to enlighten the non-tech manager here, I think an analogy is in order.

Let’s say you’re building a house. Would you use nails or screws for all attaching situations?

No. Depending on the kind of materials you need to bond, the needed strength, the climate it’s in, the budget, how long it should last… you either use nails, screws, glue, cement, or god knows what else.

You use the right tool for the job. It’s the same with programming languages.

A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. … But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope.

Philip Greenspun, Java is the SUV of programming tools

(I just used this quote to show that there can be some bias and strong opinions concerning certain languages. I also don’t like Java, but that’s beside the point.)

Yes, you can hammer a screw into wood (I tried this as a kid), but it will take a lot of effort and will provide less bonding than a nail. And you might hit your fingers in the process (I also did this as a kid).

Still not convinced? Do you know that some programming languages can be 100 times faster than others? And there are also other differences just as relevant as execution speed.

And though execution speed can be important, it shouldn’t be your guiding factor.

Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

Yukihiro Matsumoto, Ruby programming language on Wikipedia

People sometimes dismiss Ruby because Ruby is slow. Well it is, and I don’t care. The biggest performance bottlenecks that I have day to day is the database, the file system, the internet and bugs. These are not problems with Ruby, so speeding it up will have a negligible effect.

Additionally, hardware is cheap and developers are not. If you can use a programming language like Ruby to make your programmers more productive, then you can increase the performance of your code with better hardware. You can buy the better hardware with the money you saved by making your developers more productive.

Graham Jenson, What is Ruby? It is fun and makes you happy!

I once was part of a team that had to make an internal web application. We didn’t have any Java experience, but the company already had some customer-facing Java web apps developed by the ‘webdev’ team. So we agreed to use Java.

After evaluating several Java frameworks, one of us bumped into this new thing called ‘Ruby on Rails’ (V0.11 at that time iirc). ‘Rails’, as it’s often called, was like a breath of fresh air after being bombarded with Java that seemed more like configuration than programming at that time.

There was only 1 problem: Rails uses Ruby instead of Java as its programming language.

Even so, we decided to go for it. We finished the project in considerably less time than the original estimate. This also helped management accept that we had neglected to use Java.

Was this all because Rails somehow made us work faster?

Not really, but it was very suited for this job, it was a really fun language (it still is), it was new and exciting, and because we were supposed to use Java, our asses were on the line in a major way.

It was the right tool for the job AND the right tool for us. By the way, last time I heard, this application was still running (I no longer work there).

And when we showed the hardcore Java aficionados, one comment really struck: “it’s easy that way.” And this wasn’t the last time I heard this (often concerning Ruby). And shouldn’t that exactly be the whole point? Making things easier?

Unfortunately, when technology is concerned, the decisions aren’t always that clear and we rely a lot on other (less?) relevant factors to guide us.

Why your devs might not like a language that makes their lives easier

When I started out as a pro programmer, the company I worked for made client software in a not-so-easy language/framework. Why? Primary reason: they wanted the software to be as fast as possible, which is very valid.

Unfortunately, the database technology we were using was so damn slow that any advantage the faster language offered was totally obliterated. This was a huge bottleneck. The language was like a Ferrari, but it was waiting 98% of the time for the database’s traffic light. And that light won’t switch to green faster just because there’s a Ferrari waiting.

(For the tech guys: we were using C++/MFC and an Access database through ODBC… ok, stop laughing, we eventually switched to faster database tech.)

It also took several minutes to compile the project, meaning that we couldn’t just make changes and test them right away. No, we had to wait several minutes to test things, or get an error (and in the old days, that could have been several hours, but only graybeards remember this).

When I suggested that another language/technology (Delphi) was really more suited for the job, colleagues argued: “there’s no demand for Delphi programmers, this isn’t good for us.”

They were right. For me, this was my first job and I wanted to make a good impression. However, they had already proven themselves, knew this wasn’t going to be their last job and didn’t want to lock themselves into a framework/language that wasn’t in demand.

And I have no idea if they would have been able to find Delphi programmers.

Besides that, we could be pretty sure that Microsoft (the manufacturer of the tool we used) would still be around in a couple of years… while Borland (the original developer of Delphi) always seemed to be hovering on the edge of bankruptcy.

Would we have been more productive using Delphi? I’m pretty sure we would have. It was just much more suited for what we were doing and more forgiving for the rather average developers we were.

Would it have been good for the company? Not if the devs ran away and couldn’t be replaced by others.

Would it have been good for me? In hindsight, no. Now I can put 8 years of ‘pro’ C++ development on my CV, which is a lot more impressive compared to Delphi/Pascal. A lot of people used Pascal in high school, so it’s often not taken seriously.

So how do you pick a suitable language/framework?

You should use what startups use!

That’s what I used to tell the CxO’s. And I was wrong, as most of them didn’t work for startups.

Tech startups are the hotbed of technology. They use cutting-edge tools and make amazing software that scales to millions of users. And you will have to look hard to find startups using Java/C#.

Why?

Technology is at the core of their business, and their goal is to grow fast or fail fast – which probably isn’t yours. You are probably looking for stability, and aren’t interested in failing, no matter how slow or fast it goes.

You’re part of a startup? You should have brighter guys on board than me who will tell you what language/framework to use. And pssst: don’t waste your time reading this, you’ve got a startup to grow!

So, should you just stick with classic, proven tech then?

Hell no!

The language and framework you use can make a real difference. I think that except for certain edge cases, the human impact far outweighs the technological impact.

Have your programmers experiment with alternatives. Even if they don’t get all excited and suggest ditching your current tools, they might just find them useful somewhere. Also, it will help to fight boreout and keep things interesting.

Depending on the kind of software you make, it might be worth investigating domain specific languages (DSL).

This is something that could motivate the seniors and benefit everyone.

I have worked in EDI in the past, and DSL’s would be perfect there. Of course, I’d do it in Ruby, but I’m biased.

But isn’t it hard to learn a new language?

The basic logical building blocks of all languages are more or less the same. To compare programmers to writers again: a good programmer can tell a solid, logical story, no matter what language or framework (s)he uses.

Regular learning will also make it easier to learn new things in the future. I like to think of this as keeping your ‘learning muscle’ in shape.

And it will certainly not hinder career opportunities to experiment with other tools.
Au contraire mon frère.

Finally, it will also help you attract new talent. A business that uses Java, but with some Ruby, PHP and Node.js where it makes sense, sounds a lot sexier to the kind of people you want (well, it does to me).

Some have even suggested using technology as a hiring filter.

“The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.”

Paul Graham, Great Hackers

But don’t take my word (or Paul’s) for all this. Your mileage will vary. There are too many different situations to provide a ready-made answer. I hope I still gave you some food for thought and provided some insights though.

If there’s any meager advice I could give it would be this:

Talk to your developers
Are they using the right tools for the job?
Encourage experimentation. Without experimentation we’d still be using assembler (or gasp: Cobol!).
Have them investigate DSL’s.
Remember that this isn’t purely a tech/HR matter.

And know that something will always go wrong, and it often isn’t the technologies’ fault.

Had a good read? Sign up at here to get notified of future (dis)informative articles by email.

Agree? disagree? Let me know your thoughts in the comments.

Header image by Duncan Hull, used under CC BY 2.0.

Your Developers Aren’t Bricklayers, They’re Writers

March 30, 2015 / Piet / 31 Comments

This article got voted Best “Everything Else” Article of May 2015 on CodeProject.
It trended on Reddit, where it generated an at times heated discussion.

If you have ten programmers, the best one is probably at least five times better compared to the worst one. No shit.

Define better: he works faster, produces less bugs and writes more readable, logical and maintainable code.

Programmers aren’t bricklayers or carpenters, but they are often treated as such. (not that there’s something wrong with these occupations)
“Why would I get a senior when I can get two juniors for the same price?”
“This feature takes three months for one programmer? Let’s just put two more on it so we can have it in a month.”

And why is that? Because there’s no decent, fool-proof way to measure the productivity of a programmer, I guess? Whatever can’t be measured, gets ignored. I’ve seen it too many times. [Tweet]

Also: would you rather have two juniors deliver your baby, fix your car, perform a lumbar puncture, or would you rather have one senior? Despite popular belief, the act of producing code is not a commodity. [Tweet]

The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

Robert Glass, Facts and Fallacies of Software Engineering

If you really want to compare, then I’d say programmers are more like writers.

Some writers can produce a page turner that goes on to sell millions, while another might produce something that is so boring it extinguishes the fire it’s thrown in!
Yet, they both produced a book and thus they’re both writers, and you wouldn’t know the difference unless you’d really start reading the book.

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

Fred Brooks, The Mythical Man-Month

Let me give you an actual (yes, IRL) example

(Names have been changed to protect the innocent.)
The Company (no, not the CIA, just some software company) needs to implement a new module in their flag product. Mr. Lousy is free at the moment; great, let him start right away!

After four months of tinkering, Mr. Lousy is finally finished. The QA team finds loads of bugs and inconsistencies that need to be reproduced and reported back to Mr. Lousy. He then spends two weeks fixing those bugs and finally delivers a new version! Those are damn annoying bugs and Mr. Lousy often thinks about them while he stares into the distance.
This test/fix cycle is repeated two or three times.

The users have been promised this new module. Sales will be able to sign with some new customers that have been waiting for this module. There’s considerable pressure to just get it out there and it gets incorporated in the next release. Hurray! Champagne for everyone!

Unfortunately, the new module is still rather buggy. Customers are excellent at finding previously undetected bugs. So they contact support. The support team tries to find out what’s going wrong, whether the customer’s confused about the feature, whether they’re confused themselves, or whether it’s just a bug and can be reproduced. Yada, yada, yada. They decide to file a bug report. Unfortunately, Mr. Lousy is wreaking havoc—oh, I mean he is working on another project at this time, and he can’t just drop everything to fix them pestering bugs.

(And we haven’t even talked about whether the code is maintainable, logical and documented. Because sooner or later someone else will need to make enhancements, add features, etc.)

But, uh-oh…there are some bugs that Mr. Lousy can’t seem to fix. Also, new bugs turn up and no one is sure if they are indeed new, or just weren’t discovered before. Support gets pestered. Sales are getting annoyed, because those new customers find the module is too unreliable for day-to-day work and want to cancel their contract!

And, finally, the boss asks Mr. Rockstar Developer to take a look at the code.

Mr. Rockstar isn’t really able to make heads or tails of it and sees lots of senseless constructions. He advises to rewrite the code, thinking it’ll take about a month. He gets to work and hands over the finished module in just a few days longer than his original estimate (he’s Mr. Rockstar, not Mr. Perfect). Besides some minor bugs that are quickly detected by the QA team, everything works as expected. The QA team starts to worry: if they’d all be like him, they’d be out of a job. Mr. Lousy thinks that Mr. Rockstar is an arrogant twit, but this isn’t really relevant.

The revised module gets released. Everybody is happy because it finally works. Hurray!
Congrats! Rejoice! Champagne again!

By this time, it’s usually forgotten that Mr. Rockstar managed to do in about one month what Mr. Lousy couldn’t in 7-8 months.

The huge difference between these two developers only surfaced here because they performed the exact same task.

By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.

Phil Haack, 10 Developers For The Price Of One

Now, what is the worst that could happen here?

Mr. Rockstar eventually notices that he’s considerably more productive than Mr. Lousy. And, don’t be fooled, he doesn’t need to get the same task to find out. This is his job; he’s damn good at it and he easily recognizes bad code written by a bad programmer. Still, he’s pretty sure (or absolutely sure) that Mr. Lousy is earning more or less the same amount of pay. He gets disgruntled and/or he quits. And you’ve just lost a considerable amount of production power for your development team.

Even if he doesn’t quit, how do you think he’ll feel when a release/project is running late and the whole team is ‘punished’ with overtime? This is the inevitable waiting to happen.

If you’re really out of luck, he’ll be replaced by another Mr. Lousy.

So, why does this go unnoticed so often?

Because it’s easier to ignore this issue than to fix it—at least up to a certain point, and also because no one likes to rat on colleagues and be the cause of someone losing his job; because Mr. Lousy has three kids and just bought a new house; and, most importantly, because it’s very hard to measure a developer’s productivity, unless you’re really able to compare them both doing the same task as in the above story.

Are you a developer? Do you agree? Please let me know in the comments. Almost all non-tech people think ‘one developer day’ is an exact measurement. [Tweet]

Now, I’ve been thinking a lot about this: measuring a developer’s productivity. I’ve often been jealous of salesmen because their remuneration is based on their accomplishments. I’ve got some ideas (still ripening) on how to separate the wheat from the chaff. I’ve also been thinking about and will be posting about how to identify, attract and retain the Mr. Rockstar developers.

Who am I and why am I telling you this

I’ve worked as a professional developer (that is, getting paid for it during a daytime job) for over 10 years. I made my first commercial product (a game) in 1989. Although this didn’t make me rich, it still felt great (I was 16 at the time). A couple of years later, I sold the idea of one of my games, and it eventually got released on the Nintendo Gameboy (and other formats) by Bandai! I can tell you from experience that it’s very satisfying to see something you thought up (including the name) actually being sold in a shop.

In 2008, I took a non-tech job at a very technology-driven company. I wanted to learn about running a business in general, about the sales process,… everything non-tech that happens in business. Well, my tech chops probably got me hired and are still very useful, but they are no longer an essential part of the job.

I don’t program for a living anymore (or rather: at the moment), but often tinker with various new technologies in after-hours projects. To me, it’s the same as reading a good book—exciting and relaxing at the same time.

In my current role, I often encounter people who express certain misconceptions or who lack basic knowledge of the development process. In their role (often CxO), this basic knowledge could make a huge difference.

Enlightening them isn’t on our agendas during these encounters and I usually just leave it at that. When appropriate, with the CxOs who I know on a more personal level, I’ve tried to convince them of their incorrect or incomplete view of the software development process (usually to no avail).

Now, because I like to think via writing, and I really think I can provide value here, I’m making a series of blog posts about the various clichés and misconceptions I’ve encountered in this industry.

Header photo by Moresheth, used under CC BY 2.0 / Cropped from original

Generating a twitter OAuth access key – the semi-manual way

October 26, 2010 / Piet / 2 Comments

[UPDATE]
Apparently someone at Twitter was listening, or I’m going senile/blind. Let’s call it a combination of both.

Instead of following all the steps below, you could just login with the Twitter account you want to use on http://dev.twitter.com, register your application and then click ‘Edit Details’ on the application overview page at http://dev.twitter.com/apps. Next click the ‘Application detail’ button on the right, followed by the ‘My Access Token’ button in order to get your Access Token and Access Token Secret.

This makes the old post below rather obsolete. Clearly a case of me thinking everything is a nail and ruby is a hammer (don’t they usually say this about java coders?) 😉

[ORIGINAL POST]

OAuth is great! OAuth allows your application to use your user’s data without the need to ask for their password. So Twitter made the API much safer for their and your users. Hurray! Free pizza for everyone!

Unless of course you’re using the Twitter API for your own needs like running your own bot and don’t need access to other user’s data. In such cases a simple username/password combination is more than enough. I can understand however that the Twitter guys don’t really care that much about these exceptions(?). Most such uses for the API are probably rather spammy in nature.

!!! If you have a twitter app that uses the API to access external user’s data: look for another solution. This solution is ONLY meant when you ONLY need access to your own account(s) through the API.

Authenticating with the Twitter API: old vs new

Acessing The Twitter API the old way:
[sourcecode language=’ruby’]
require ‘twitter’
httpauth = Twitter::HTTPAuth.new(‘my_account’,’my_secret_password’)
client = Twitter::Base.new(httpauth)
client.update(‘Hurray!’)
[/sourcecode]

The OAuth way:
[sourcecode language=’ruby’]
require ‘twitter’
oauth = Twitter::OAuth.new(‘ve4whatafuzzksaMQKjoI’, ‘KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY’)
oauth.authorize_from_access(‘123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis’, ‘fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh’)
client = Twitter::Base.new(oauth)
client.update(‘Hurray!’)
[/sourcecode]

In the above case,
ve4whatafuzzksaMQKjoI is the ‘consumer key’ (sometimes also referred to as ‘consumer token’) and
KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY is the ‘consumer secret’. You’ll get these from Twitter when you register your app.

123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis is the ‘access token’ and
fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh is the ‘access secret’. This combination gives the registered application access to your account. I’ll show you how to obtain these by following the steps below.

(Basically you’ll need a bunch of keys and you’ll have to jump a bit through hoops to obtain them for your server/bot. )

How to get these keys

1. Surf to the twitter apps registration page

go to http://dev.twitter.com/apps to register your app. Login with your twitter account.

2. Register your application

Enter something for Application name, Description, website,… as I said: they make you jump through hoops.

If you plan on using the API to post tweets, Your application name and website will be used in the ‘5 minutes ago via…’ line below your tweet. You could use the this to point to a page with info about your bot, or maybe it’s useful for SEO purposes.

For application type I choose ‘browser’ and entered http://www.hadermann.be/callback as a ‘Callback URL’. This url returns a 404 error, which is ideal because after giving our account access to our ‘application’ (step 6), it will redirect to this url with an ‘oauth_token’ and ‘oauth_verifier’ in the url. We need to get these from the url. It doesn’t really matter what you enter here though, you could leave it blank because you need to explicitely specify it when generating a request token.

You probably want read&write access so set this at ‘Default Access type’.

3. Get your consumer key and consumer secret

On the next page, copy/paste your ‘consumer key’ and ‘consumer secret’. You’ll need these later on. You also need these as part of the authentication in your script later on:

[sourcecode language=’ruby’]
oauth = Twitter::OAuth.new([consumer key], [consumer secret])
[/sourcecode]

4. Obtain your request token

run the following in IRB to obtain your ‘request token’
Replace my fake consumer key and consumer secret with the one you obtained in step 3. And use something else instead http://www.hadermann.be/callback: although this will only give a 404, you shouldn’t trust me.

[sourcecode language=’ruby’]
irb(main):001:0> require ‘oauth’
irb(main):002:0> c = OAuth::Consumer.new(‘ve4whatafuzzksaMQKjoI’,
‘KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY’,
{:site => ‘http://twitter.com’})
irb(main):003:0> request_token = c.get_request_token(:oauth_callback => ‘http://www.hadermann.be/callback’)
irb(main):004:0> request_token.token
=> “UrperqaukeWsWt3IAlfbxzyBUFpwWIcWkHP94QH2C1”
[/sourcecode]

This (UrperqaukeWsWt3IAlfbxzyBUFpwWIcWkHP94QH2C1) is the request token: Copy/paste this token, you will need this next.

5. Authorize your application

surf to https://api.twitter.com/oauth/authorize?oauth_token=[the above token], for example:

https://api.twitter.com/oauth/authorize?oauth_token=UrperqaukeWsWt3IAlfbxzyBUFpwWIcWkHP94QH2C1

This will bring you to the ‘An application would like to connect to your account’- screen on Twitter where you can grant access to the app you just registered. If you aren’t still logged in, you need to login first. Click ‘Allow’. Unless you don’t trust yourself.

6. Get your oauth_verifier from the redirected url

Your browser will be redirected to your callback url, with an oauth_token and oauth_verifier parameter appended. You’ll need the oauth_verifier.

In my case the browser redirected to:

http://www.hadermann.be/callback?oauth_token=UrperqaukeWsWt3IAlfbxzyBUFpwWIcWkHP94QH2C1&oauth_verifier=waoOhKo8orpaqvQe6rVi5fti4ejr8hPeZrTewyeag

Which returned a 404, giving me the chance to copy/paste my oauth_verifier: waoOhKo8orpaqvQe6rVi5fti4ejr8hPeZrTewyeag

7. Request an access token

Back to irb, use the oauth_verifier to request an access token, as follows:
[sourcecode language=’ruby’]
irb(main):005:0> at = request_token.get_access_token(:oauth_verifier => ‘waoOhKo8orpaqvQe6rVi5fti4ejr8hPeZrTewyeag’)
irb(main):006:0> at.params[:oauth_token]
=> “123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis”
irb(main):007:0> at.params[:oauth_token_secret]
=> “fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh”
[/sourcecode]

We’re there!

123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis is the access token.
fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh is the access secret.

Try it!

Try the following to post an update:

[sourcecode language=’ruby’]
require ‘twitter’
oauth = Twitter::OAuth.new(‘ve4whatafuzzksaMQKjoI’, ‘KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY’)
oauth.authorize_from_access(‘123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis’, ‘fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh’)
client = Twitter::Base.new(oauth)
client.update(‘Cowabunga!’)
[/sourcecode]

Now you can go to your twitter page and delete the tweet if you want to.

MODx character encoding

October 23, 2010 / Piet / 0 Comments

Ahhh character encodings. Don’t you just love them?

Having character issues in MODx? Then probably the MODx manager character encoding, the character encoding of the site itself, your database’s character encoding, or the encoding MODx/php uses to talk to MySQL isn’t correct.

The Website Encoding

Your MODx site’s character encoding can be configured in the manager under Tools/Configuration/Site/Character encoding. This is the encoding your website’s visitors will get.

The Manager’s Encoding

The manager’s encoding can be changed by setting $modx_manager_charset at manager/includes/lang/<language>.inc.php like this (for example):

$modx_manager_charset = 'iso-8859-1';

To find out what language you’re using (and thus was file you need to change), check Tools/Configuration/Site/Language (1 line above the character encoding setting).

This needs to be the same encoding as your site. You can’t have your manager in utf8 and your site in iso-8859-1.

Your Database’s Encoding

The charset MODx/php uses to talk to your database can be set by changing $database_connection_charset in manager/includes/config.inc.php. This needs to be the same as your database’s charset. Make sure you use the correct corresponding charset, for iso-8859-1 you need to use ‘latin1’. Utf8 is just utf8.

Example:

$database_connection_charset = 'latin1';

Now, if you check Reports/System info, the ‘Database Charset’ might say something else. This is because the mysql variable ‘character_set_database’ is displayed here, which contains the character set used by the default database and not the one for the current database/connection.

However, if you’d change this to display ‘character_set_connection’, it could still say something else because the ‘set character set’ statement used by MODx doesn’t change this value either. The ‘set names’ statement does, but since it turns out my MODx install works now as expected I’ll just leave it at this before I get a headache.

If I saved you a potential headache or you think I’m totally wrong or overlooked something, let me know in the comments.

btw: I want to be able to use a real editor with MODx. Somehow.

The hidden cost of interrupting knowledge workers

November 5, 2009 / Piet / 2 Comments

The November issue of pragpub has an interesting article on interruptions. The article is written by Brian Tarbox, who also mentions the article on his blog. I like the subtitle: ‘Simple Strategies for Avoiding Dumping Your Mental Stack’.

Brian talks about the effective cost of interrupting a ‘knowledge worker’, often with trivial questions or distractions. In the eyes of the interruptor, the interruption only costs the time the interrupted had to listen to the question and give an answer. However, depending on what the interrupted was doing at the time, getting fully immersed in their task again might take up to 15-20 minutes. Enough interruptions might even cause a knowledge worker to mentally call it a day.

According to this article interruptions can consume about 28% of a knowledge worker’s time, translating in a $588 billion loss for US companies each year.

interruptions can consume about 28% of a knowledge worker's time, translating in a $588 billion loss for US companies each year Click To Tweet

Looking for a new developer to join your team? Ever thought about optimizing your team’s environment and the way they work instead?

Making non knowledge workers aware

You can’t. Well, I haven’t succeeded yet. And believe me: I’ve tried. When you’ve got a simple way to really increase your productivity (‘give me 2 hours of uninterrupted time a day’) it wouldn’t be right not to tell your boss or team-leader about it.

The problem is: only productive knowledge workers seem to understand this. People who don’t fall into this category just seem to think you’re joking, being arrogant or anti-social when you tell them the interruptions can really have an impact on your productivity.

Also, knowledge workers often work in a very concentrated mental state which is described here as:

It is the same mindfulness as ecstatic lovemaking, the merging of two into a fluidly harmonious one. The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task.

Yes, coding can be addictive and if you’re interrupting a programmer at the wrong moment, you’re effectively bringing down a junkie from his high in just a few seconds. This can result in seemingly arrogant, almost aggressive reactions.

How to make people aware of the production-cost they’re inflicting: I’ve been often pondering that question myself. The article suggests that solutions based on that question never seem to work. To be honest: I’ve never even been able to find a half decent solution for this question. People who are not in this situations just don’t understand the issue, no matter how you try to explain it.

Fun (?) thing I’ve noticed: Programmers or IT people in general who don’t get this are often the kind of people who just don’t get anything done.

Interrupt handling (interruption management?) IRL

Have non-urgent questions handled in a non-interruptive way

It helps a bit to educate people into using non-interruptive ways to ask questions: “duh, I have no idea, but I’m a bit busy here now could you put it in an email so I don’t forget?”. Eventually, a considerable amount of people will skip interrupting you and just send an email right away. Some stubborn-headed people however will continue to just interrupt you, saying “you’re 10 meters from my desk, why can’t we just talk?”.

Just remember to disable your email notifications, it can be hard to resist opening your email client when you know a new email just arrived.

Use Do Not Disturb signals

When working in a group of programmers, often the unofficial sign you can only be interrupted for something important is to put on headphones. And when the environment is quiet enough, often people aren’t even listening to music. Otherwise music can help to block the indirect distractions (someone else talking on the phone or tapping their feet). You might get a “they’re all just surfing and listening to music”-reaction from outsiders though.

Peopleware talks about a team where the no-interruption sign was placing a shawl on the desk. If I remember correctly, I am unable to locate my copy of this really excellent must-read book.
If you have all standardized on the same IM tool, maybe that tool has a ‘do not disturb’ setting. Also some phone-systems have a ‘DND’ (do not disturb) setting.

Hide

Brian offers a number of good suggestions, some obvious like: hide away somewhere they can’t find you. Not sure how long it’ll be till someone thinks you’re just taking a nap somewhere though. Also, this often isn’t possible or your boss might not understand this. And if you really get caught taking a nap, make sure to explain that your were powernapping.

Counter-act interruptions

Another suggestion he offers is when you’re being interrupted to just hold up your hand, blocking the interruption, and at least giving you time to finish your sentence or your block/line of code. The last suggestion works more as a way to make it obvious to the interruptor that they really are interrupting your work and to offload some of the cost on the interruptor. In practice, this can also helps you cool down a bit so you don’t start saying nasty things to the interruptor.

Unfortunately I’ve sometimes been confronted with people who just ignore this signal and keep talking, as if they’re sure that whatever they’ve got to say is really worth listening to and without a doubt more important than anything you might be doing.
This behaviour usually leaves me speechless (not good when someone just asked a question). I’ve noticed that these people are usually also the first to complain when being interrupted themselves. They’re generally not very liked as colleagues, so try not to imitate their behaviour.

TDD as a way to minimize recovery time

I don’t like Test Driven Development. Mainly for only one reason: It interrupts flow. At least, that’s what it does for me, but maybe I’m just not grown used to TDD yet.

BUT a positive effect TDD has on me when I have to work in an interruptive environment and can’t really get into the ‘flow’ (also supposedly called ‘the zone’ by software developers, although I’ve never heard it 1st hand), TDD helps me to concentrate on the tasks at hand and helps me to get back at work after an interruption. I feel when using TDD, I can get by without the need for being totally ‘in’ the project and I can be reasonably productive without obtaining ‘flow’.

Do you have a suggestion on how to make people aware of the concept of ‘flow’ and the cost of interruptions? (without looking like an arrogant ass or a weirdo)

Twitter gem – undefined method `stringify_keys’

September 9, 2009 / Piet / 0 Comments

Have you been getting the following errors when running the Twitter gem lately ?

/usr/local/lib/ruby/gems/1.8/gems/httparty-0.4.3/lib/httparty/response.rb:15:in `send': undefined method `stringify_keys' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/httparty-0.4.3/lib/httparty/response.rb:15:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/mash-0.0.3/lib/mash.rb:131:in `deep_update' from /usr/local/lib/ruby/gems/1.8/gems/mash-0.0.3/lib/mash.rb:50:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/twitter-0.6.13/lib/twitter/search.rb:101:in `new' from /usr/local/lib/ruby/gems/1.8/gems/twitter-0.6.13/lib/twitter/search.rb:101:in `fetch' from test.rb:26

It’s because Twitter has been sending back plain text errors that are treated as a string instead of json and can’t be properly ‘Mashed’ by the Twitter gem. Also check http://github.com/jnunemaker/twitter/issues#issue/6.

Without diving into the bowels of the Twitter gem or HTTParty, you could ‘begin…rescue’ this error and try again in 5 minutes. I fixed it by overriding the offending code to return nil and checking for a nil response as follows:

[sourcecode language=’ruby’]
module Twitter
class Search
def fetch(force=false)

if @fetch.nil? || force
query = @query.dup
query[:q] = query[:q].join(‘ ‘)
query[:format] = ‘json’ #This line is the hack and whole reason we’re monkey-patching at all.

response = self.class.get(‘http://search.twitter.com/search’, :query => query, :format => :json)

#Our patch: response should be a Hash. If it isnt, return nil.
return nil if response.class != Hash

@fetch = Mash.new(response)
end

@fetch
end

end
end

[/sourcecode]

(adapted from http://github.com/jnunemaker/twitter/issues#issue/9)

If you have a better solution: speak up!