Producing the best product in the least amount of time with the right amount of resources is all about efficiency. Here in Copenhagen I heard someone say today to be careful about making sure that nobody was blocked, that you helped anyone who needed help. The reason why this is important is that most projects will cascade a block downstream ending in a much larger delay than the original issue. For example, if you are waiting for the system architect to finish specifying an API, you’re blocked (as the implementer), but so is anyone who relies on your code or the QA team who tests it. There are many ways to solve these situations, mocks, fakes, etc. For example, when doing UI layout, I used to stick in a “FPO image” that was the right size so we could put the elements around it. On the command-line side, I used to just have my API return fake data until I could implement each feature. There are hundreds of other solutions. The goal was for me to implement the minimum so that everyone else could get started on their job and eliminate myself as the project bottleneck.
A great example of efficiency is what our hotel in Copenhagen has done with the elevators, with what I presume is an elevator scheduler. There is no up or down button, instead you enter what floor you want to go to. In theory, this allows the elevator to more efficiently schedule its trips. If there are people going to 10 different floors, say 3-7 and 21-25, it can send two elevators and the latter will be an express right to 21. With information gathered over days and months and data input about room usage, the elevators could stage themselves efficiently as well, up high in the mornings and in the lobby in the afternoon.
The elevator key pad asks for your room number.
The elevators also only hold about six people, so instead of two large elevators, they use several smaller ones. If you have people going to a bunch of different floors they get split up into different elevators. After you enter your floor it tells you which elevator, you should wait in front of, this avoids you having to look around for which elevator to use. Then to improve efficiency more, it pre-selects your floor; when you enter the elevator your floor button has already been “pushed”. This is especially helpful in a crowded elevator in an international hotel when calling out “Seis, por favor” may not be understood by the person near the buttons.
Elevators were a major problem at the Oakland UDS where in the morning and evening there was large delays of up to 20 minutes to get on one. My roommate and I gave up on taking the elevator later in the week and ended up taking the stairs. When UDS starts up next week we’ll see how these keep up, but I’m hopeful they’ll work out.
So what does this have to do with code? Other than pondering how one might write an elevator scheduler and feed usage patterns back in for more efficient routing, the real point of this post was me just thinking about efficiency. When you’re working on a project, you should take a brief moment to consider who you are blocking and how you can solve that. More than likely, if you spend ten minutes to help someone who is stuck, the payoff for your project will be hours or more once the downstream effects are realized. You don’t want to be the elevators at the Oakland UDS, you want to be the elevators at the Copenhagen UDS.
EDIT: Since I’ve not done any research on this, does anyone know if the elevators really are using an intelligent scheduler? If you do, please comment.