Recognizing Signals #scrum #xp #agile #lifehack

Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.

Painful Facts For Developers #programming #foss

I recently saw a note from the Tech Journalist Russell Holly who calls on the Scumbags of the Internet to stop making demands of developers from whom they get their free software:

You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.

I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts:

Continuing Our Solitary Existence #xp #agile #scrum #programming

It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.

There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.

Today’s Noise, Tomorrow’s Dinosaur #programming #business

I was inspired by Driving Technical Change to write this. Please read the following for context:

Expertise, even for the very experienced, is a fluid thing. With the exception of abandoned technology, every tool, technique, or product that you are trying to push is changing everyday. The producers are adding more features. The community is posting more commentary. Users discover bugs, and product teams fix them. Nothing is static. Therefore, even the most expert of experts is only as good as the last thing they read. There is no standing still as an expert. And yesterday’s expert is tomorrow’s dinosaur after as little as two years of not keeping up.

I think this is a sweeping generalization which I believe is wrong, and I know is wrong for me. I regularly go on sabbatical for 3-6 months where I don’t or hardy use a computer, with hardly I mean I checked my mail once after 3 months. In this time due to the fact that I’m traveling I don’t read computer books or magazines. Coming back after this time I notice one important thing, nothing has changed except the version numbers. New features have been added to old software, new design patterns have been thought up and new frameworks have been created, whole sections of the linux kernel have been rewritten. And with in a week I am at my expertise level, and a week later I have covered most of the important things I’ve missed.

People who follow changes live are often stuck in the noise of the present, which for an expert a timeline can often look like this:

1. Somebody suggests or codes a feature
2. Feature is discussed on a mailing list and in chat
3. Feature is attacked for obvious weaknesses
4. Feature is tested and updated
5. Feature is implemented in the alpha
6. Feature breaks when combined with other updates or breaks other features
7. Mails/articles are written for and against the change
8. Patches are exchanged and evaluated
9. Feature undergoes further testing
10. Feature reaches the beta
11. Discussions on the direction of the software
12. Possibly a branch is created
13. Feature is updated in next beta
14. Discussions on the feature
15. Articles are written about the new features in the next release
16. Feature is released
17. Articles are written about the new feature
18. Revisions of books on the software or framework are written which include the new feature

This can take anywhere up to 6 months for larger features or changes to large frameworks. Following the noise allows you to adapt to the change over a longer period of time, and allows you to experiment more with the feature. This same result can be reached by reading the articles which are published round the time the feature is live, with the exception of the generated noise. One of the advantages is that this noise can be used for reference material, when the noise is of good quality. And this example covers only one feature for one software package or framework.

Being caught up in the daily noise also has a bigger problem. In some cases I may not be a direct contributor to a software package or framework and this noise can reduce the time that I can spend learning other things from the new books or articles which cover the other areas in which I consider myself an expert.

Something which is also neglected in the statement above is that experts have often been their and seen that. CVS works similar to SVN, which with a context shift works similar to Git. Each solving a different problem, and with the knowledge of the problem being solved it is easy to apply previously learned unrelated knowledge to new software or a new framework.

A great book!

Creating a Solution for Everybody? #business

I often build nice tools for myself, often customize them to myself with no regard for what a general users wants or needs. This is because it’s for me, and not for another, before I decide whether I release this under GPL or try to sell it I always ask myself the following questions before I make it ready to ship:

• Is there really a problem?
• Does my audience have this problem?
• Is there a solution which is better for my audience?

Let me take you through my thought process so you might better understand what I mean.

Is there really a problem?

In the case of some solutions I create, like the Roxen CMS or the YouTube Unsubscribe scripts I wrote, there really is a problem for others and myself. This doesn’t mean that everybody has this problem, just that I have it and that others probably have it too. It a problem with an easy solution, and something which can be quickly put together and released.

With other things I create, such as my script to take the items I download with Juice and order them in bundles sorted by audio, video, document or other, there is a clear problem for me, and this might not be a problem for others or this might not be the solution for others.

Does my audience have this problem?

In the case of the YouTube scripts there was clearly a problem for others, this functionality was not available. For Roxen CMS it was a case of this making life easier. Looking even further back I wrote a script which added a mark (un)read button for GMail rather than going into a pulldown menu to mark (un)read, this was downloaded quite a number of times and offered something that Google was not offering at that time.

Is there a solution which is better for my audience?

This is always a question, the solution I create is often the best for me or the best which was available at the time. It doesn’t have to be a good solution for others at all, it might not even work for others because it is too customized to my user experience that it neglects the user experience of others.

Taking the case of the Juice script all the directories are hardcoded for my system, they might work for somebody else and they aren’t designed to. The current version doesn’t clean up after itself, which means there is quite some mess left after the scripts are run. It deletes everything it doesn’t know, so it doesn’t take into account things that my audience might want such as images.

Image source: arjin j

Inspired by Productivity #lifehacks #mashable

I was reading a Mashable item on productivity^[1] which contained some interesting things that I will turn into a slideshow on this week.

Do NOT check your e-mail for the first 45 minutes that you are in the office in the morning. […] There are never meetings at that time and most people are settling in and reading their e-mails, […] — Amanda Feifer O’Brien, Marketing Manager at Firmenich Inc.

Take the first 30 minutes to plan the rest of your day. By plan, I mean make a list of the important tasks that you need to have done today and stay focused on these items. […] Make a list of the things that you want to achieve that day and work from that list until it’s completed. — Rohan Hall, Founder and CEO of rSitez, Inc

This is an excellent way to start the day, I have been using the 43 Folders system to unplan the year, this is my scheduled backlog, and take the day folder out and add this to my daily TODO list – which I write on Post-its. While creating the initial Post-its I like to create Post-its which contain:

• Lunch
• Coffee Break (x4)
• Snack Break (x2)
• Mail Break (x2)

And interspace these in the timeline of the day.

On my whiteboard I arrange the Post-its in the following grid:

First I take the Not Urgent and Not Important and bin them, obviously there is no reason to do them or they would have been graded differently.

Next I estimate the time and importance needed for the Urgent and Important tasks, and split the longer items into shorter tasks. Then I start the tasks by solving some of the important short tasks first to set the tone of the day to task completion, then I process the remaining tasks in order of importance. I like to use timeboxes for each of the tasks based on my estimates.

Next I estimate and complete the Not Urgent and Important items and don’t move on to estimating and completing the Urgent and Not Important until I’m finished.

1. 37 Productivity Tips for Working From Anywhere

Image source: Dennis Hamilton

Company Policy or People #hr

I find a 400 plus page manual of office policies and job descriptions for each position in the office slightly excessive, I know few people who read manuals like that back-to-back unless they are finding ways to make a company policy work in their favour, or a loophole. You’ve just given them 400 plus pages of potential loopholes, unless it’s written by a lawyer, then you have given them 400 plus pages of information which is impenetrable to them, and in which they will have to pay a lawyer to find the loophole which is almost certainly in there.

Even if the average employee could read, understand and recall 400 plus pages of information at 1 page a minute it would still take them 6 2/3 hours to read the manual. Do they get paid for these hours? What if it takes them slightly longer?

Employees are often asked to go above and beyond the call of duty, these job descriptions and policies are a disadvantage for the company also. I’ve seen companies give detailed job descriptions – including a specific location – and then have a policy which contradicts this by saying that location and duties are determined by the company. I’ve seen high-value producers leave because overanxious HR departments following policy without using judgement have send official warnings on first offense policy violations, they go to competitor companies were the working environment was less hostile.

Read more articles on Human Resources…

I’m not saying to have a 400 plus page manual which covers office policies and job descriptions isn’t helpful, it can be very valuable. Although I’ve found that companies who give their employees manuals which stretch to 400 pages are usually companies, and specifically HR departments, who need a way to exercise control which they do not have. Perhaps it is wise to look at the company structure and size, and regain the control by having control.

(Image source: stikone)

The Ladders’ fictional Betty Boss is hiring #recruitment

The Ladders created a fictional recruiter Betty Boss and interviewed her for the newsletter. They also share the reasons Betty didn’t hire me, so I would like to respond to fictional Betty Boss:

Hi Betty, thanks for allowing me to respond.

I never saw your resume

That’s true, you asked the recruiter to not reveal the company they were hiring for. They also couldn’t tell me the price they wanted to pay for my skills, so I didn’t send it. In the same way I am one of many, you are also just one of many.

Agilo: a SCRUM tool # agile #scrum

After reading Scrum and XP from the Trenches I was interested in tools to help me implement SCRUM into my projects. Firstly I looked at what the author recommended. In a blog article he advised visiting userStories for inspiration. This in turn led me to Agilo. I downloaded the appliance and tried it out.

At first I was happy, it was an integration of Trac, which I know quite well as a developer, although not as an admin. Which lead me to the first issue, documentation… In projects documentation is one of the easiest things do do wrong, once such case is to not Test the documentation. This is a SCRUM requirement for the software and should also be for the documentation. Luckily I was experience enough with Trac and Apache that I could quickly discover what the issue was.

This is what I needed to do, in the form of a simple script, to add a new project:

#!/bin/sh

PROJECT=$1

cd /var/lib/trac/

# Make Trac
sudo trac-admin $((PROJECT)) initenv
sudo trac-admin /var/lib/trac/$((PROJECT))/ upgrade
sudo trac-admin /var/lib/trac/$((PROJECT)) permission add admin TRAC_ADMIN
sudo chown -R www-data:www-data $((PROJECT))

# Deploy FCGI
sudo trac-admin deploy /tmp/deploy
sudo mv /tmp/deploy/* /var/lib/trac/crypto-disk/
sudo rm -rf /tmp/deploy

# Make SVN
sudo mkdir /var/lib/svn/$((PROJECT))
sudo chmod -R www-data:www-data /var/lib/svn/$((PROJECT))/
svnadmin create /var/lib/svn/$((PROJECT))/
sudo chown -R www-data:www-data /var/lib/svn/$((PROJECT))/

cat <<EOF
        <LocationMatch /$((PROJECT))/login>
                AuthType Basic
                AuthName "Agilo for Scrum"
                AuthUserFile /var/lib/trac/users.passwd
                Require valid-user
        </LocationMatch>
        <Location /$((PROJECT))/svn>
                DAV svn
                SVNPath /var/lib/svn/$((PROJECT))
                AuthType Basic
                AuthName "Subversion Repository"
                AuthUserFile /var/lib/trac/users.passwd
                AuthzSVNAccessFile /var/lib/svn/$((PROJECT))/conf/authz
                Require valid-user
        </Location>
EOF

This last piece of data needs to be inserted into the /etc/apache2/sites-enabled/000-default/, or what ever the default Apache config file is for your Agilo site is for your installation. And then restart Apache

sudo /etc/init.d/apache2 restart

A nice piece of Agile SCRUM software.

Computer Aided Translator

As you may or may not know I like linguistics, I played with Word Sense Disambiguation using a number if the corpus’ available. I’m not a linguist, the closest is being touched by linguini. *pastafarians groan*

As of today I’m investigating adding another arrow to my bow, and because of this I’m learning about Computer Aided Translation tools. Soon I may become a part-time translator, from Dutch to English.

technorati tags: translation, business, dutch, english