In a comment to my earlier article Thoughts on Kanban someone brought up the subject of end dates. Businesses obsess about the “When can we have it?” question. Dates and deadlines trump all. Let me tell you a secret: dates are bullshit. It is a prohibitive mentality in today’s world. Technology needs to reframe the question. Stakeholders need to change their engagement. No company ever succeeded because they made dates. Companies succeed when they continuously deliver innovation. It is not about the destination. It is about the journey and where you end up.

For agile to truly succeed the DNA of the company–top to bottom–must be continuous improvement through continuous delivery.

I Want Everything. Now.

A friend told me a story of a prioritization meeting he had with a stakeholder. After fleshing out seven distinct features with the dev team, the stakeholder was asked to prioritize. He walked up to the board, put a “1″ next to everything, and walked out.

Really? Everything is a top priority? So you are saying you would rather have nothing than anything? Then what you want is worthless. You may think you need everything but you are showing your unwillingness to change or improve. People that cannot work through small changes definitely cannot deal with large ones.

Yes, long-term vision is important. It is the goal. It ensures that everyone heads in the right direction every step of the way. It helps people make reasonable decisions. But it is still long-term; it is just a vision of the future negating the small details that allow the day-to-day. It is painful, ridiculous and unnecessary to wait for the future to just “appear”.

Long term deliverables create impatient, anxious users. It creates large, unmanageable codebases, complex releases, excessive bugs. It disconnects original vision from delivered functionality. The cherry on the cake: it creates a confused user base making awkward and painful adjustments to radical new processes. There is no long-term goal that cannot be broken down and reached via small iterative releases. Baby steps. One at a time, together. It is a three-legged race for everyone.

The Devil Is In The Details.

This is the root cause of scope creep. Okay, we’re working on feature x, but can we do this? Can we do this? What about this? You tell me. Is it more important for you to do that or get what we have out? It is your call! When you look at the backlog is it more important to enhance the current feature or move to the next thing on the list?

We have daily scrums to answer the improve or move question. Get involved in the day-to-day. Transparency is king. If you don’t trust the person making the call then don’t let them make the call. Empower key people: it’s an organizational change which pushes agile forward.

Active engagement between stakeholders and developers is agile development. The less barriers between the two the better. Getting a common sub-conscience understanding of “what we are doing” is the key to success. Small companies align on vision easily. Large companies need to break up into teams and align on goals.

Deadlines Get Things Done

You want to know if this really complex thing you are asking for can be done in eight weeks? Can you spell out every possible detail, define every wireframe, tell me how it should look on every device to every user in the world, outline every workflow, specify the amount of load it requires, explain how you will want to enhance it in the future, not bother us at all while we build it, let us decide any confusing or ambiguous detail, then maybe, maybe, I can do this thing that nobody has ever done before in eight weeks. If eight weeks later when you are unhappy with that one thing you did not explicitly specify (even though I totally asked you to specify everything) I will tell you “It wasn’t in the reqs”.

Is that how you want to work? Or would you rather tell me the gist of what we are doing, come up with a plan to get there, see what we can do first quickly, get it out, then take it from there. Is outlining every validation error on every page necessary to do now or can we start with the first page and take it from there?

You may also use deadlines to motivate people. Vision, direction and importance also motivate people. It is pretty easy to get something done by saying “This needs to happen by this date”. But that shows you do not care what it does or how well it works. You are asking people to time box something because either the details are irrelevant or there is no trust in people to make the right decisions.

Always Be Releasing

Releasing functionality does not mean users have to see it. Turning features on and off, experimenting with small audiences, refactoring one class rather than an entire stack; all these are powerful steps for modern companies to improve products. Constant feedback lets everyone know they are headed in the right direction. It lets dev teams know the health of their code base. What is better than actually integrating new code to production to test integration? What is better than knowing if a feature is worth investing in than testing it on a small set of production users?

I’m sure you heard about the cone of uncertainty. Small and explicit features with short estimations can be delivered accurately. Larger loosely defined features with long dates are difficult to predict. Break down large features into small, clear user stories. A big feature or a long date means you do not care about details.

Short date ranges are okay and can help coordinate people. They work well when matched with story size. A few days, one week, one to three, and three to five are good ranges which require a decent discussion to work out details. Ranges allow for adjustment and can be refined as you move along the uncertainty cone. Ideally they are auto-calculated from story points. Anything +5 weeks requires a break down; there are too many variables. Don’t think you can add up ranges either, that is not the way it works. It is about increasingly clarifying level of detail on what’s ahead to maintain momentum. You can still, and should, deploy intermittently within the date range. Long dates don’t provide detail. Without detail you do not care how features work. So you do not care what you get.

You Work For A Tech Company

Your type of business does not matter. Your size does not matter. In house, off shore, outsourced development does not matter. It’s 2012. Your company uses technology to do business. You work for a tech company. As a tech person your job is to help your business realize this. As a stakeholder your job is to realize this and help your tech team help you do your job faster, better, easier.

I’ll Say It Again: Always Be Releasing.

Good companies consistently take their products to the next level. How? They build an incredible manufacturing pipeline. Why is Toyota’s just-in-time practices so applicable to building software? Because development teams manufacture software. It’s how the product is built. It’s how it changes. It’s how it’s delivered. It’s how it’s fixed. Dev teams buy the land, construct the building, build the robots, define the pipeline, assemble the pieces, run quality control, load up the trucks, deliver and when all that is done they improve. Hopefully the new manufacturing plant allows for easy improvement. Otherwise somebody made a mistake.

Faster, Better, Stronger

It is everyone’s responsibility to ensure that manufacturing pipeline delivers as efficiently as possible with no flaws. Continuous integration, unit tests, programming languages, server frameworks, agile development, clear vision, well written stories, cohesive vision, user feedback; it all goes into building a solid manufacturing process. You do not need to get it right the first time. You just need to change and improve when needed. Tech leaders ensure they are building the right process for the business. Stakeholders enable and leverage that pipeline effectively. Radical product changes, disconnected vision or tech decisions lead to numerous and slow manufacturing plants.

Dates are bullshit. It’s about where you are, where you want to be, and what’s next. That’s the conversation.

• Update: I missed a section of date ranges matching to story points relating to the cone of certainty. Short date ranges are a good tool for predicting near term deliverables and framing what’s next. These ranges is most effective when your agile tool auto-calculates velocity from story points.

By far the trickiest part of building the single speed bike (and, consequently, the most fun) was building the wheel.  I was a little hesitant to take on wheel assembly, but I couldn’t cop out and not try to give it a shot.  It turns out, it’s rather easy and a lot of fun.  Once you get the pattern down lacing the spokes is pretty straightforward, and out of all the parts of bike building this step really connects you to the bike.

The first round of spokes are in. Luckily, the Rebel Yell was close at hand.

The Wheels

The wheels are a pair of Velocity Deep V‘s with Origin-8 branded hubs (they’re actually made by Formula).  The spokes are DT Champions.  Luckily, I didn’t have to worry about calculating spoke length because I ordered everything from Ride Brooklyn (a great bike store in Park Slope) and they took care of the details.

Videos

I did a lot of research before I got started.  Books weren’t that helpful, as you really need to learn by example to mimic what’s going on as you lace the spokes.  I found the best video on building a 36 hole front wheel from the bike tube on YouTube. I’d just skip to wheel building part two where the action starts.  The bike tube also has two videos on lacing a 32 hole rear wheel.  It’s the same lacing pattern, but the video goes into a little more depth when building the wheel.  The three cross pattern (which means a spoke crosses three other spokes between the hub and rim) is the same between front and rear wheels.

The first set of spokes are in. Notice the spoke next to the valve hole. The second set of spokes should go in to the right of this one, so it doesn't straddle the valve hole. Or, you can start one away from the valve hole, and string the second set between the valve hole and the first spoke. The alternate side spoke goes in the flange hole immediately adjacent to the spoke on the opposite side.

I recommend watching both sets.  The approach is a little different in that the 32 hole front wheel has you lace one side first, then the other, while the 36 hole rear wheel has you lace alternate sides (you put in for sets of spokes: the “innies” and “outies” on both the left and right flange).  The valve hole ends up being in a different place with the rear wheel video- as the author explains, you want it to be between a parallel set of spokes to make using the valve easier.  With the front wheel video the valve ends up being between a slanted set of spokes (I could have also followed the video incorrectly).  Not a big deal; it’s just a nuanced difference.

I recommend following the 36 hole front wheel video- it’s a little easier to get the hub centered in the flange because you lace alternate sides.  My rims have 32 holes and there really isn’t any difference in building the wheel.  (A 36 hole wheel has 4 sets of 9 spokes each, while a 32 hole wheel only has 8 spokes per set).

I followed the 32 hole rear wheel video, which laces one side at a time. It proved difficult to lace the 2nd side because the hub wasn't centered.

Getting Started

I followed the rear wheel video because it was more succinct.  However, I messed up in the process and had to start again.  I laced one side, and the hub was off center- one side was flush with the rim.  This made lacing the second side very difficult, as there wasn’t a lot of give in the hub.  I also had a hard time figuring out where to start lacing on the second side.  I started with the wrong hole, and the hub got very twisted half way through the second side.  I really had to pull to get the nipples connected.  When it proved extremely difficult, I knew I must be doing something wrong.  If you’re fighting the wheel, stop and restart.  You missed something. After starting again, I realized where I went wrong the first time with the second set of spokes on the other side.

Notice how the second set of spikes line up with the valve hole. This will put the valve hole between parallel spokes.

Try, and Try Again

When I attempted to build the wheel again, using the front wheel video, the process was a piece of cake.  Every spoke went in without a hitch.  The benefit of alternating sides while lacing is the hub is centered in the rim which makes connecting the spokes to the nipples very easy (although, I could have messed that up too when following the rear wheel video).

The only glitch (which was a minor issue) is when I did the first wheel the valve hole didn’t end up between parallel spots.  I either messed up following the video, or the front wheel video didn’t make a point to lace the wheel in such a way.  The rear wheel video does explicitly call this out.  As long you don’t end up with the valve hole in a cross spoke triangle you’re all set.  Then it will be impossible to fill the tire with air.

It's a nuanced difference, but you want the valve hole between parallel spots.

Correcting the error when I did the rear wheel was easy- I just started one hole away from the valve hole, rather than right next to the valve hole.  After I twisted the hub to get the spoke slant to start the second side, I made sure I started the second side next to the valve hole.  This way the two slanted spokes are next to the valve hole, rather than straddling it.  This will put the valve hole between parallel spokes.

The wheel after lacing the second side.

Truing

Once I got all the spokes on the wheel I dropped some wet lube on the nipples and tightened every spoke with a screwdriver until only a couple threads remained.  The front wheel came out pretty straight, but the rear wheel was way off.  It just took a little more work with the spoke wrench to get it center.  I came up with a make shift truing stand with the front fork and some plastic sticky tabs (I needed to use the frame to do the rear wheel, but it’s the same idea).

Awesome makeshift truing stand, with helpful plastic sticky tabs used in lieu of calipers.

I placed the sticky tabs as close as possible to the frame and spun the wheel (the wheel spun forever- the hubs must be really slick!).  When the frame hit the tab it would make a noise, and I would adjust.  It’s really hard to see the space shift between the tab and the rim.  The noise thing really helped.  Slow and calculated increments worked best- you really only need a quarter turn.  This approach worked for both the horizontal and vertical trueness.

I have no way of properly checking the dish, so I may need to take a trip to the bike store (dish is making sure the hub is centered on the rim).  I’m also worried that the spokes are too tight.  I read that you shouldn’t have a lot of spoke tension- the spokes feel firm but I definitely need a second opinion.

What’s Next

I’m hoping to get the rest of the parts tomorrow to finish this build.  I’ll have another post to show how it all came together!

As we’re getting ready to gear up for summer, my wife was looking for a new bike.  I wanted to get her something cool and unique, and (selfishly) use the opportunity to indulge myself in a bike building project.  I heard building a bike was a pretty straightforward process, and in a worse case scenario I’ll just bring the parts to a bike shop and have them finish it up.  We knew we wanted to go with a single speed- a friend has a Trek Soho S which I fell in love with.  A single speed is perfect for jetting around the city- really light and nimble.  The acceleration is surprisingly easy and you hit a nice cruising speed quickly.  I’m anxiously awaiting to compare this custom build with other commercial bikes.

The Bike

We headed over to the good folks at Ride Brooklyn for a recommendation on what to buy.  It’s a great bike shop with a really friendly and helpful staff.  My wife wanted something light and we both wanted to keep the cost down.  They had two frames handy for comparison: An Origin-8 track frame and a slightly more expensive 183rd Street track frame.  The 183rd Street frame was a lot lighter than the Origin-8 (surprisingly so) and has a nice powder coat paint job in black which gives it a cool matte finish.  The owner built a bike using the same frame, so we figured it was the way to go.  My wife is 5’4″ and we got the 51cm frame and fork.

Half the parts ready to go. My boss says only in NYC do you build a bike in the kitchen.

We also got a pair of Velocity Deep V rims in lime green with Formula hubs and a purple Origin-8 crank.  Once I saw everything together this bike is definitely getting a nickname: “The Joker”.

The Build: Bottom Bracket

With parts in hand, it’s time to get building!  I started with the bottom bracket, which is an Origin-8 cartridge style bracket with a length of 107mm.  It turns out I should have gotten the 103mm, but the 107 will work just fine.  Check the specifications of your crank to find out for sure (I thought it would have to do with the frame, but it’s sized for the crank).  I followed this video from Bicycle Tutor to find out what to do.  It’s pretty straightforward.  Honestly, the hardest part was figuring out how to get the lock cup off the bottom bracket.  Hint: You just pull it off!  I kept turning it and was afraid to pull too hard.  Turns out, not a big deal.  I borrowed a bottom bracket tool, but didn’t have a torque wrench to find the right resistance.  Using some polylube 1000 to grease the threads,  I just screwed the bracket until it was pretty tight and checked the turn on the spindle.  Seemed alright.  I couldn’t get the lock cup flush with the frame on the non drive side, but it turns out this isn’t a big deal.

The Headset

The 183rd Street frame has a threadless 1 1/8″ headtube.  I picked up a Crane Creek threadless headset, and, funny enough, used their great video on how to install a threadless headset.  I didn’t have a threadless headset press, and tried using a 2×4 and a hammer to get the bottom and top cups on.  It didn’t work.  Lesson learned: Don’t try using a hammer to bang your threadless headset on the frame.

Headset fully pressed on frame, but text is off center

Fork with crown race installed. You can see the sticky tabs I used to true the wheel.

You need the right tool for the job.  I didn’t want to buy a tool, so I brought the headset and frame back to Ride Brooklyn (I should start a side bet to see how many times I need to go back there!) and they pressed the cups on the frame, and used a crown race setter to put the crown race on the fork.  I did mess up a little bit, because I forgot to center the logo on the cups when I put them on the frame. I already had them half on when I went to the store and didn’t want to deal with taking them off again.

Next Steps

Lacing and truing the wheel was a fun but tedious process.  I’ll write about that next as well as putting the other parts together, so check out the BikeBuild tag to follow on the progress.

I recently moved this blog and some other smaller websites to a virtual machine running on Rackspace Cloud. So far I’m loving having my own server, and have been able to get my hands dirty with Linux administration, apache, and mysql.

But one quirk was really bothering me: at times, my WordPress blog would hang. I don’t get too much traffic, and using

[code lang="bash"]top[/code]

showed no real load on the cpu. But there were a lot of Apache threads with a good chunk of memory allocated, and I had a little free memory available.  I tried adding more memory to the server, but no luck.  I thought the issue could be mysql, but running queries wasn’t a problem.  Neither was static html- the root index.html loaded quickly.  So that left php itself.

A couple of apache config changes didn’t help.  The thing which really did the trick was installing eAccelerator.  This tool simply keeps the compiled php script available, so apache doesn’t have to recompile the php script on every load.  No, the blog is a lot faster and much more reliable.

Installation is easy on Fedora (or CentOS, or whatever distro uses yum):

[code lang="bash"]sudo yum install php-accelerator[/code]

then just restart apache and you’re good to go:

[code lang="bash"]sudo /sbin/service httpd reload[/code]

If you don’t notice an immediate improvement, and want to check to make sure it’s loaded, then create a info.php file with the following code:

[code lang="php"]<?php phpinfo(); ?>[/code]

and you should see the accelerator info in the list.

fox glacier sunset at lake-24, originally uploaded by mhamrah.

I’ve been playing around with HDR photography after coming back from an incredible vacation to New Zealand. This photo came out especially well.