HOW to commit to nothing

In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the third being COMMIT TO NOTHING. In this post, I'm going to talk about how to make this (not) happen ;). Things to think about. Tips and tricks. I could almost write a book about each point here, but I'm not going to put you through that.

1 First: WHY?

Simple. When you commit to nothing, achieving it is easy ;)
Of course, this is a bit tongue in cheek. You're going to have to deliver SOMETHING at some stage, because, well, if you don't, you won't get paid.
"Commit to nothing" really means "Manage expectations VERY carefully".

2 Committing to nothing is NOT THE SAME AS SAYING NO

Devs, a lot of times, have a reputation as the ones who can only see problems. The ones who's first response to anything new or exciting is "NO".
In a world where there's a lot of noise generated when things break, but everyone quickly gets used to everything working 100% fine, this is a natural defence mechanism. But it slows down progress.
Rather than "No, because…", you should aim for "Yes, but…".
"YES - we can do this last minute rush project for you, BUT… which items/projects would you like us to delay instead?".
"YES - I think that idea should be possible, BUT… we're going to need to investigate, to figure out timings and impacts".
"YES - we can talk about this scope change, but would you rather have us talking about the new feature, or finishing the stuff we're scheduled to work on now?".
You get the idea: All work is really a matter of logistics. How many hours of development time available, vs how many are needed to get all the things done. Communicating the difference is vital. This is why Rule#2 - TRACK EVERYTHING is so vital: when you have data on how long things take, you're able to negotiate and estimate with confidence.

3 Time is your friend

Unless you're in a mission critical "production is down" type of incident, there's no need to make decisions or commitments in real time. No work should be undertaken unless the estimations and planning have been done. This doesn't mean that you should be delaying unnecessarily. You should be working as fast as you can to reduce uncertainty and get a reliable, dependable estimate and impact assessment out. Agile needs less certainty and upfront estimating to get started than Waterfall - so the amount of scoping you do depends on requirements of the methodology.
Say "I'll get back to you", and then do that.

4 The people doing the work make the estimates

It doesn't matter if you have consultants telling you how long things SHOULD take. It doesn't matter if you're a team lead, with experience in the tasks, and have an opinion on how long you WOULD take. It doesn't matter if you have the CEO ranting and shouting in front of you telling you how long you MUST take. The only people making that call will be the people actually doing the work. Whether it's by providing the estimate, and sticking to that, or taking whatever time is dictated, and delivering to the time they would have estimated anyway, the team actually doing the work determines the delivery date.
You'll need the entire team to chip in with estimates for their bit. Make CERTAIN the team is in "Estimation Mode" - in a planning session, or similar. When hearing about the concept for the first time, or sitting in a meeting with CLIENT is not the right time. If you're a lone dev, this whole story still applies. You need time away from everyone to think carefully about what needs to be done…

5 Remind everyone that you're committing to nothing. Regularly.

Unless you're constantly reminding people that NOW is not the time in which you're committing, that THIS discussion is only about what MIGHT be possible, but you're not committing to anything, your statements on whether things are possible, or how achievable you THINK things are will be taken as absolute, iron-clad commitment by the CLIENT - who is under intense pressure to get things done.

6 When you DO commit, DELIVER

All of this "I'm committing to nothing now" talk will upset people, and things could get quite heated. You want to make people's problems smaller, not bigger. Introducing "uncertainty" into the situation by repeating the mantra "I commit to nothing" is not going to help calm things down. It is vital that, when you DO commit, you DELIVER. When you first get a request to do something, don't commit to doing it, but do commit to getting back with a first-pass estimate in some near timeframe. Within 24 real-time hours is preferable.
When you send the first pass, make sure to be clear about what you are and aren't committing to yet. Usually, you still need to run some spike solutions and do more research to get to a nice level of certainty. From the first pass, you should be able to give estimates for when you will have the scope planned to a level you're willing to commit to. And so it goes.

7 Conclusion

By being careful about the expectations you create, you increase certainty: building a reputation of dependability, one round of work at a time.

8 Glossary:

• CLIENT: the person who will ultimately say the work is done. In the Agile setting, the Product Owner.

< How to track all the things ...  ... How to deliver >

[edit] - added image

HOW to track all the things

In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the second being TRACK EVERYTHING. In this post, I'm sharing a bit about actual ways to make this happen. Things to think about. Tips and tricks. I could almost write a book about each point here, but I'm not going to put you through that.

1 time, Time, TIME

I can't say enough about time tracking. It's vital for your ability to deliver consistently to be good at estimating, so when you're asked to DELIVER, you can :)
OUTLINE & ESTIMATE: Break down the project into finer and finer pieces, until you have items with a MAX of 4 hours estimated effort. It's always about time. I know, I know, Story Points are about complexity. But, inevitably, you end up talking about Velocity - which is really about points per Sprint, which is a time-box. Your estimates are best "Naive". How long it'd take you to do this bit of work, if you were working on just this task, and weren't experiencing interruptions. Time to execute, not actual time for this to be done. So it excludes time spent waiting for other people to check/code reviews/budget approvals or whatever. If you KNOW you're going to need a code review, that's a separate task, with its own estimate.
TRACK ACTUAL: The point? - you're trying to see how accurate you are when estimating. Track your actual time taken, and at the end of the week/sprint/project/whatever, have a look at your estimated vs actual times. Learn from this, see if you can figure out ways to bring the two figures closer together. It also doesn't hurt to be able to say (and back it up with figures) that you track every minute of your day.

2 Master the tracking systems you're given

Most companies have some sort of timesheet system they subject the workforce to. Understand that this isn't going away. It is to your ADVANTAGE to become a pro at it. I use Emacs org-mode, and then funnel data from THAT into whatever system HR is running. The reason? usually, the HR system can't help with planning or estimating. With org-mode, I can outline, estimate, track and report, all from one system, at a much richer level than any other system I've encountered. And I'm in full control of the original data, so it won't get lost or mangled. And I'm able to process and query it for interesting insights.

3 Track conversations with writing

After any meeting, deskside chat or watercooler session in which a decision or agreement is made, back it up with a mail. Or other written medium - as long as you can go back to it later. You can check on it and remind yourself what to do (so not wasting anyone's time) - and in the event of disagreements/arguments, you'll have something to refer to. It sounds stupid, assuming everything could turn into a persecution session, but remember: TECHNICALLY CORRECT IS THE BEST CORRECT.
Make default choices/assumptions. And share the choices in writing. This helps move things forward faster, and you're minimising the risk of people having nasty surprises by letting them know beforehand what you'll be doing. Of course, only do this when you have run out of other options, such as reading the briefs, chatting/mailing/texting whomever you need advice from etc.
Need an answer, decision or output from someone? Feel free to do so in person, over the phone, or in the hallway. But make sure you back this up with a mail or other long-term written record.

4 Use Analytics

TRACK EVERYTHING applies to your apps/websites too. It's vital for you to know and understand what's going on inside them. Whether you use New Relic or Google Analytics, make sure you're able to see what's happening in your app/site. Mostly, you're instrumenting for the reasons you CAN'T think of. A bug will emerge, and you'll want historical data. Your site will get hit with a ton of traffic, and you'll want to see if there were patterns to people's behaviour. That sort of thing. Often, analysis is done, and people say "wouldn't it be nice if we had xxx data or yyy detail?". Do your level best to make it so this is never said of the work you do.

5 Track your progress with notes/documentation

Coding is difficult enough. Remembering state for the myriad projects you're on is crazy. Do yourself a favour, make notes, and have a 5 minute break. It doesn't matter whether you make the notes in the source code, some text buffer or post-its - the important thing is to do it.

6 Rather over communicate than under

Keeping CLIENT calm whilst you're solving their problems is half the battle. Remember: they aren't telepathically plumbed in to what you're seeing, and the progress you're making. So it's vital that you give regular updates. How regular depends on the client and what you've agreed upon as well as how urgent the job/task is. Even if you have nothing to say, other than "I'm still investigating" - let people know you're working on their stuff. Don't lie. If you're only going to get to their stuff later, that's OK, just let them know.

7 Bonus: WHY to track all the things

Simple, really. When you've made an audit trail of what you're doing, you don't have to remember trivial details, like when you started and stopped a task, and what you were doing last Tuesday. If you're a contractor, you're already focused on this, either because you're billing by the hour, or have committed to a fixed-cost project, which is based on estimated hours… If you're permanent, remember: you've signed an agreement for x many of your hours per day. It is optimal to work that number of hours per day. Any more, and you're being exploited. Any less, and you're stealing ;)

< How to deliver ...  ... How to commit to nothing >

[edit] - added image

HOW to Deliver

In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the first being DELIVER. In this post, I'm sharing a bit about actual ways to make this happen. Things to think about. Tips and tricks. I could almost write a book about each point here, but I'm not going to put you through that.
Some useful tips for delivering

1 What's the actual problem here?

Often, you're told to do X to fix Y problem. Spend a couple of minutes figuring out if Y is really a problem, and if there isn't some better/easier way than X to fix it. I've saved countless hours with this.

2 What can be done RIGHT NOW, and then what is the correct solution?

There's always a problem with time. Figure out the absolute bare minimum that needs to be done RIGHT NOW to solve the problem. Then think about how to solve correctly. You might only have time to figure out the RIGHT NOW solution, but you'll be aware that it's going to need attention later on.

3 Naive estimate first, THEN optimise.

Don't waste mental cycles and time trying to shoe-horn everything into an elegant, efficient model or schedule from the start. Treat each part as if you were doing only that part. As the scope becomes more concrete, you can optimise for re-use, common functionality etc.

4 Figure out what needs to be done first

Sounds obvious, but your predisposition for linear thought is acting against you here. You need to weigh Urgency vs Importance vs Difficulty vs "Force Multiplication" vs "Internal Setup Time". Using these, you'll end up with a sometimes non-obvious order of execution that is better.

5 Sub 4 hour resolution

Aim to have no task estimated at longer than 4 hours to complete. This seems like overkill, but trust me - paying this much attention when estimating means you're much less likely to overlook things. And you end up with a plan that can tell you, within half a day, whether you're ahead or behind schedule.

6 Spike solutions

For things that are unknown, or difficult, use a spike solution. Zoom in on the specific technical problem you're trying to solve, figure out the smallest possible thing you have to do to solve the problem, and solve just that problem. The point is not to solve the larger problem: it's to help you understand unknowns, so you can better plan your way forward.

7 Solve end-to-end, then polish.

An inefficient, badly written complete solution is better than the most elegantly written incomplete solution. Get something working that solves the problem as quickly as possible, then focus on parts that need refactoring or rework. Unless you're building an Air Traffic Control System. Then get it right the first time.

8 Notes, for start-stop work

Do yourself a favour: keep yourself well informed. Never assume you're going to remember everything. Write notes down (either as comments in the code, or separately) as you go.

9 Work in bursts

I typically never work for more than 50 minutes without taking a break. Often, taking a break is just getting a cup of coffee, going to the loo, or reading an article for 10 minutes. Work hard, and reward yourself with little breaks. Most of the time, better approaches or insights happen when I'm NOT at my desk, thrashing out code…

10 Remove distractions

Plan for "available time" and "unavailable time". Disable notifications as much as possible. Check your mail once every hour or two only, and schedule actions from the mails, rather than trying to deal with them on the spot. Work from home. Find an isolated spot at the office somewhere.

11 Multiply force

Have sections of work that others are waiting for you to do, before they can move on? Kill those ASAP. Try never to have people waiting for you.

12 AUTOMATE

macros/scripts/applications/other people - "Anything worth doing twice is worth automating" is maybe taking it a bit far, but repetitive tasks are best done by machine or multiple other people - you're just being a bottleneck otherwise.

13 Glossary

• Spike solution: notes here: http://www.extremeprogramming.org/rules/spike.html
• Urgency: Anything that must be done NOW - that's holding up other people, or preventing people from using your software correctly, or closing a lead/sale is Urgent.
• Important: Anything that will have a big impact on your business/unit/app/site in future. Often expressed as "let's worry about that later" by the suits, until it becomes Urgent.
• Difficult: Anything that you can't get your head around in an hour or so. When you answer a question of whether something can be done, and you initially say "no" - it's likely difficult.
• Force Multiplier: https://en.wikipedia.org/wiki/Force_multiplication explains well, but basically, if you can build a tool, app or process that allows many other people to do work on your behalf, or get it done automatically, that's a force multiplier.
• Internal Setup Time: "Internal setup activities are those that require the process to be at a standstill before you can conduct them safely while external activities can be done while the process is still running." (check out http://setupreductiononline.com/ for the full story). Yes - the roots are in the changeover of press dies, but there are many parallels and lessons to be learned for software engineering. If you can find a way to reduce internal setup time, the process of making something new or fixing/repairing happens much faster.

< How to commit to nothing...  ... How to track all the things >

[edit] - added image

Three rules for sustainable and enjoyable work.

Over the last twenty years or so, I've consistently been a productive member of whatever team I've been in. As a subordinate, peer or superior, I've consistently rated highly on the "productive", "great to work with" and "all round nice guy" scales - sometimes to the detriment of my physical and mental health. Eventually, I figured it would be better to try and work "sustainably", rather than "AWESOMELY!!!". At the end of the day, I reckon your boss, or the client, or whomever it is you're working for, more than anything else, wants to be able to depend on you to be able to make THEIR problems smaller, not bigger. Counter-intuitively, working sustainably, not ridiculously hard and fast is the way to do this.

There are a thousand things you need to pay attention to, but they can be lumped into three categories of action - I call them three "rules". Really just a set of overall principles to guide your actions. Here they are:

Rule #1: DELIVER!!!
People like managers and clients love this one, and for good reason. It's comforting to hear that there's a set of rules, and that number one is "DELIVER!!!". It's really simple: someone (let's call them the CLIENT from here on) has the rank to look at your work and declare it "delivered". Your job is to make it so they can. This does not mean "exceed all poorly articulated expectations" or "work 20 hour days because someone is expecting you to do so". "Delivered" will mean different things at different times - between projects and even whilst projects are running, but you will only ever be able to "DELIVER!!!" when you know what "DELIVERED!!!" means, and who the CLIENT is. How...

Rule #2: Track all the things
ALWAYS keep track of what is happening during delivery. ALWAYS get what constitutes "delivered" on record, and make sure the CLIENT gets copies. ALWAYS track all the FACTS. This is not about proving your version vs. the CLIENT's version - it's about what really happened - because you can use that data to figure out how you can better DELIVER!!! in future. How...

Rule #3: Commit to NOTHING!!!
Yes - you just read that. This doesn't actually mean "never commit to anything" - rather, it means "ensure that you can deliver whatever you commit to". Anything you (even vaguely) commit to will turn into an expectation on the CLIENT's end. Your CLIENT's job is to squeeze you as hard as possible for as much delivery as possible, as soon as possible. YOUR job is to achieve your goals (whatever they are) by delivering as efficiently as possible. If you commit to doing the things you are sure you can deliver, delivery is assured. How...

In Summary:
These three aspects combine in a harmonious little feedback loop. When you're getting all three right, you will be approached for difficult and important, time critical work that is highly rewarding, because CLIENTs will know that you can make their problems smaller without adding drama to their lives. Or yours.

[edit] - title tweaked
[edit] - added links to "how" items
[edit] - added image

Hole-otron9000, ukiyo-e and stickers.

I'd much rather make something than write about it, but, well, I have my online presence to maintain, so here's something:

I think, because I work on code, and shiny new things all the time, I'm fascinated with old tech. It can be anything, from how Romans built aqua ducts to steam power. I was looking into how horn-backed sinew bows are made (as one does),  was looking for the recipe for the glue that would have been used at that time - and, among other things, found a recipe for "mucilage".

It's the lick-and-stick glue on those old style stamps...

cool. Now, my wife, being a junior school teacher, could potentially make use of this sort of thing - teachers are always on the lookout for stickers to put in books, so this could just work...

I ran off a couple of prints at the local copy shop, slapped the mucilage on the back, ran a perforated cutter over them and handed them over for testing.

Cute, and they worked nicely. But of course, I wanted to see how far I could take things, so I carved up some lino, and hand printed and aligned some stuff:

Of course, because I was going for a certain look and feel - those little punched holes in the paper, I built a machine to make that happen:

Here's a clip of the last little bit of punching, and the system resetting for the next sheet of paper:

I also ended up printing using a traditional Japanese method - because it gives a very pleasing look, is highly economical, and doesn't require fancy equipment like presses and such to turn out prints of decent size. David Bull has got some really great videos, and you can see the process and beautiful results on his channel: 

https://www.youtube.com/user/seseragistudio

I'm slowly moving to making a vending machine (entirely manual) for the stickers. See you in two years :)

Zamboni Pile and electrostatic pendulum

Here's what the setup looks like at the moment:

That's the pile there at the top of the pic, in a clamp.

The pendulum and plates

Pendulum in action.

I've known about the Oxford Electric Bell for quite a while, but could never figure out how it was made. I just assumed the tech was lost, and folks would only know how it was made once it stopped and they dismantled it. The thing has been running since 1840, is still going, and they might have to replace the clapper, because it's getting out of shape.

Somehow - some random youtubing and googling a couple of weeks ago led me to think that it might be possible to get started making a Zamboni pile, which is the battery used in the whole thing.

Turns out it's cheap and easy to make all this stuff.

Here's the recipe:

Grab some zinc-carbon batteries. In South Africa, "Eveready Gold" brand does the trick. Extract the manganese dioxide (black powder), mix with just enough water to make it into a paint like consistency, and then coat some paper on one side with the stuff.

Let it all dry

Glue aluminium foil to the other side of the sheet, so you've got the dioxide on one side, foil on the other.

Let it all dry

Cut into at least 700 pieces.

Stack them all in the same direction.

Compress the stack a bit.

Play.

Getting this thing to work took... faith. There's no easy way to measure the voltage coming off it - and you need a nice high one for these charge effects to happen. It took me about a week to get all those bits of paper made and cut. Clamping the leads onto a 100v capacitor only gave the weakest little bit of current after charging for a day. At about 700v, you can *just* get some effects.

Next up: better looking, easily transportable pile and a more impressive pendulum setup.

Thanks to these folks for information:

https://www.youtube.com/watch?v=Ec5Ydsf1dT8

Music could be soothing or weird, depending on your taste

https://www.youtube.com/watch?v=kkscKsc1hno

GATE-OTRON9000

I'm in the habit of naming anything I build with the suffix "-OTRON9000". Always good for a laugh. More so when such hacks make it into production on client's systems or become useful to all and sundry :)

This quick post is about how to hack a gate remote, graft it onto a Raspberry Pi, and have a web server controlled system up and running in about an hour, so everyone in your company can open and close the gate without running around to find a remote...

No doubt I'll pretty-fy the code listings, some day, but you should get the idea here.

First, THANK YOU Raspberry Pi people for making a great piece of kit. The Raspberry Pi (in case you've been in a cave for about two years) is an ARM based computer on a little board the size of a credit card (http://www.raspberrypi.org/). It's a full blown computer, only nice and cheap. And it's got some pins on it, which allow you to talk to the outside world. Here's the one I used:

My Pi - with power input (blue), Network(grey) and output pins all wired up (red)

This one has the stock standard Raspbian image on it, possibly with a custom build of Emacs 24 on it. I don't remember spending too much time getting Emacs running on it, so it's possible that either Raspbian now comes with Emacs 24, or that the installation process for building from scratch is painless. Anyway - the other tweak is that the IP address is static. I did this by tweaking the /etc/network/interfaces file to look something like this:

iface eth0 inet static

address 192.168.1.9

netmask 255.255.255.0

network 192.168.100.0

broadcast 192.168.100.255

gateway 192.168.100.254

I took this directly from http://www.raspberrypi-tutorials.co.uk/raspberry-pi-static-ip-address/

Right now, the Pi plugs directly into a wireless router. Much simpler this way.

Then, getting the pins set up so we can do fun things with them: I found the most basic example Gordon had put together (big THANKS again): https://projects.drogon.net/raspberry-pi/gpio-examples/tux-crossing/gpio-examples-1-a-single-led/

It starts with wiring up an LED to the ground and 3.3V pin on the board, then on to actually using WiringPi to turn a light on and off. A ribbon cable, bit of wire stripping, careful counting of pins, and I had the thing connected exactly the same as in Gordon's example. Using the shell, I could enter commands to turn the LED on and off.

I then made a "press-button.sh" shell script - which looks like this:

#!/bin/bash

gpio mode 0 out

gpio write 0 1

sleep 1s

gpio write 0 0

All it's telling the Pi to do, is : set pin 0 as an output pin (gpio mode 0 out), send voltage through it (gpio write 0 1), wait a bit (sleep 1s) and then stop sending the voltage (gpio write 0 0).

Right. So we have a Rpi that can switch a light on and off. Nice, but hardly reaching out and touching the real world.

Next step: hack a remote. Ideally, I'd have had some sort of switching transistor or relay handy for this, but all I had was a photo resistor. One like this (courtesy bkbelectronics.com)

I then ripped open the gate remote, removed the battery and soldered the photo resistor over the little push button switch. If the remote had worked off 5v or 3.3v, I'd have possibly just hooked the Rpi wires that power the LED to the switch, but with 12v flying around, I wasn't going anywhere near it.

With the photo resistor in place, it was fun watching the remote light go on and off as I covered it with my hand and exposed it to sunlight. Because I was using a resistor, which looks like it went up to about 1K ohm or something when it was dark, I just wired a 12 DC transformer to the terminals that used to hook up to the battery. Without a real switch in there, it's sure to be sucking power. Long term: I expect something to burn out here, but nothing's getting hot or letting off a burned plastic smell just yet.

With an LED on one side, and Photo Resistor on the other, we have a photo-optically isolated interface, so weird spikes in voltage on the remote won't affect the Pi, and vice versa. Here's what the outside looks like:

Black thing is the gate remote, duct tape wrapped thing is the LED pointing at the Photo Resistor.

Sorry I don't have a shot of the insides, but the thing works right now, so I'm not going to mess with it.

So now, we have a way to easily trigger the gate remote from the Rpi, using a shell script. To trigger the gate remote, I'd just run the "press-button.sh" script, and that'd do the trick. But expecting folks to ssh into the Pi and TYPE stuff is a bit much. What I needed was a web page people could bookmark, so they could fire it up by visiting it.

In steps Elnode (http://emacswiki.org/emacs/Elnode). Sure, I could have put PHP in there, running on Apache, and be finished quickly, but this whole thing had only taken me about an hour so far, so I was feeling confident. Elnode is a web server, which runs inside Emacs - a highly extensible text editor. Installing and getting it up and running is easy - if you're an Emacs user. I'm not going to go into the details here, but it's a thoroughly worth it exercise to install Emacs and Elnode! Stretch yourself.

Just to see what happened, I thought I'd give it a bash. So I put a bit of elisp code together:

(require 'elnode)

(defun base-handler (httpcon)

   "Gate opener"

   (elnode-http-start httpcon 200 '("Content-type" . "text/html"))

   (shell-command-to-string "bash /home/pi/wiringPi/click-button.sh")

   (elnode-http-return httpcon "<h1>GATE-OTRON9000 Activated!!!</h1>"))

(elnode-start 'base-handler :port 9000 :host "192.168.1.9")

... Evaluating that (M-x eval-buffer) then gave me a lovely page when I visited the address:

http://192.168.1.9:9000. It just said GATE-OTRON9000 Activated!!! in big bold letters, but more importantly..

The thing worked! First time! straight off the bat. We expect the motor on the gate to be burned out soonish, but no one seems to mind, we're all having too much fun opening and closing the gate with anything with a browser and wi-fi connection.

Here's our model, Sipho, showing the sheer awesomeness of it all...

I'd upload a video. But seriously. It's a gate, opening and closing...

Just to recap - here's what's going on:

The user surfs to the web page, which is served by Elnode, running inside Emacs. The handler for the page fires off a shell script that uses the WiringPi library to turn an LED on and off. The LED is pointed at a photo resistor which is sitting across the switch of an actual gate remote. When the light from the LED hits the photo resistor, the button on the gate remote is "pressed" and the gate moves.

Duct tape, twisted wires, bash scripts and elisp at it's best!

Give it a go. It's very rewarding :)