Measure Once, Cut Twice

3 minutes, 3 hours, 3 days

Posted in agile by steve on March 30, 2010

Communication efficiency on projects is intrinsically linked to distance. Consider the following scenario: you have a blocking issue that can be answered quickly by the right person. You’re not exactly sure who the right person is but you know roughly the team or group you should talk to. It is a bit tough to describe in an email, so you need to articulate it verbally, or even better, with some drawing and wild gesticulating. The other group is:

a) Your immediate team. You lean over to the person next to you and start describing it. Within 30 seconds, they probably know if they are the right person or it is someone else. Bonus: ‘accidental broadcast’ — if you are sitting close together one or two other teammates probably overheard and may chime in. Within a 3 minutes, you have your answer and everyone is back to work.

b) Another team down the hall or on another floor. You’re not sure what their schedule is, so instead of walking over and risking the key person not being there, you book a meeting at least a couple of hours in the future just to be courteous. The meeting time-slot is at least 1/2 hour long since Outlook defaults to that. 3 hours later you have your answer.

c) Another team across the Atlantic/Pacific. You have a one or two hour window the next day that is a good conference call time for both parties. If that isn’t open, you try the next day. After the call, inevitably, there is a dangling thread so you send a quick clarification email. You get an answer the following day, unblocking you. Total calendar time: 3 days.

There are in-between brackets too. Someone who is on your team but not sitting next to you is more likely 30 minutes than 3 minutes (“I’ll wait until I get a coffee to swing by their desk”). Someone only three timezones away is likely 30 hours rather than 3 days.

But that is not the worst part. If anything goes wrong in the communication or clarification goes beyond a quick follow-up email, the communication delay typically jumps up to the next bracket. 3 hours turns into 3 days and 3 days quickly turns into 3 weeks.

At a large company with widely distributed teams three week delays happen all the time. A conference call requires a follow-up or two, a key person is on holidays for a week, people are booked during the two hour timezone window until next tuesday, and so on.

The important thing to understand is that *there is no fix*. Consider it a fundamental latency attribute of the medium. Timezones, the lack of face-to-face communication, the inability to “instant interrupt” for minor issues, less awareness of people’s “micro-schedules”, and other practical issues such as room bookings and the dreaded 15-minute-delay-while-the-organizer-fights-the-web-conference-software all conspire to alter the bandwidth of the channel.

Higher average latency and less bandwidth means people will default to trying to solve issues themselves when it could have been solved more efficiently with input from someone else. If every person on a ten person team needs to communicate on a weekly basis with someone far away, that adds up to a lot of friction.

What can be done is to organize in such a way that you don’t need to communicate across that channel as often. Conway’s law is a reflection of this. The small, co-located teams recommended by Agile methods like Scrum and XP are a realization of this. They advocate re-organizing the project backlog and/or the teams so you can avoid having to communicate across slow, thin pipes. Break up into mostly independent sub-teams. Invest in the up front retraining or knowledge transfer to make it possible.

When those 3 day or 3 week delays happen repeatedly, instead of creating more processes to improve the communication or looking towards to technology (video conferencing!) to solve the problem, try to figure out how to avoid the need to communicate in the first place.

Advertisements
Tagged with: , , ,

Things to Think About When Starting iPhone/iPad Development

Posted in iphone by steve on March 29, 2010

A co-worker recently asked me what to learn and what to watch out for when starting iPhone development. There are key decisions that you need to make early on that can make or break your project. I’m also thinking about porting my existing iPhone app to the iPad, as well as writing a new app, so now is a good time to revisit those early decisions and start on the right track.

The first decision point is native vs. non-native. Native iPhone apps are written in Objective-C and use the iPhone SDK Cocoa Touch libraries. Non-native apps can be written as web apps running in the Safari browser, developed in other development platforms like Flex and compiled for the iPhone, or developed as hybrid web/native apps using a bridging framework such as PhoneGap.

If you don’t know Objective-C it is tempting to make the native/non-native decision based on your current skill-set, but that is shortsighted. If you want to make a quality app you need to understand if your app really demands native integration or not. Obviously, if you’re doing a game or anything with significant graphics you must do a native app (although in the case of games they are often mostly C or C++, which runs fine on the iPhone anyways). But even if your UI just has complex interactive screens you’re probably going to wish you had gone native.

Non-native is fine for apps with simple, informational screens that do not have a great deal of interaction beyond basic navigation. Fortunately, getting access to hardware specific features is not a blocker. PhoneGap exists to bridge between the device capabilities and a web app. It exposes the GPS, accelerometer, camera, and other features through a javascript API. Basically it is a minimalist native app that is a framework to run a web page running in Safari. You download the source, point it at your web app, and compile it.

However, if your app is complex then you will thank yourself later if you just bite the bullet and learn Objective-C and Cocoa. In this case, there are a few considerations:

  • Interface Builder (IB). How should you use it, if at all? Options:
    • Don’t use it at all, create all views programmatically.
    • Only use it to layout major screens, do event manipulation in code.
    • Go all in and do UI layout, properties, event wiring, etc. in IB.
  • Programming style. Stick to Objective-C 2.0 unless you have prior experience using older idioms.
    • Watch out for out-of-date tutorials on the web that contain mixed programming idioms.
  • Memory management strategy. Think about your window and resource ownership structure. Stay consistent!

Doing all of the UI programmatically can lead to huge amounts of unreadable code and cut’n’paste setting of properties. But the result is very predictable. You know exactly what is going to happen and where things are set. Here is a brief example setting up a label:

UILabel *myLabel = [[UILabel alloc] initWithFrame:CGRectMake(50, 100, 200, 100);
myLabel.backgroundColor = [UIColor grayColor];
myLabel.font = [UIFont fontWithName:@“Ariel” size: 14.0];
myLabel.shadowColor = [UIColor grayColor];
myLabel.shadowOffset = CGSizeMake(1,1);
myLabel.textColor = [UIColor blueColor];
myLabel.text =@“label text”;
[self.view addSubview:myLabel];

Not too bad, but now consider a medium complexity screen may have a half dozen widgets on it. My current preference is to do screen layout and properties in IB, but to do all events and manipulation in code. This allows me to layout complex screens with multiple widgets and images visually while still not relying on IB too much. The downside is it can lead to some inconsistency. For a trivial screen with one image and a button (e.g. a tutorial screen) it seems pointless to create and manage a XIB file. But if you create it programmatically then some of your screens are represented in IB and others are not. Overall it seems worth the trade-off — all of the important screens can be mocked up and rapidly edited in IB.

Programming style is another topic to pay attention to when you are in the learning stages. There are many tutorials on the web, but not all use the same idioms. It is easy to learn from multiple sources and end up with a mixed style that can lead to inconsistency resulting in bugs. In particular, pick an approach to handling properties and stick with it. Objective-C 2.0, introduced not too long before the iPhone was first released, includes features to create properties declaratively. Unless you know what you are doing, learn this well and and stick with the 2.0 conventions.

Objective-C is the type of language that greatly benefits from consistent coding style, particularly when it comes to memory management. Your approach will depend greatly upon the application you are building, but similar to C++, the main thing is to think it through in advance. Don’t expect to do it as go you and refactor on the fly. Think through which resources are memory intensive and which are not and plan your memory management strategy around the memory intensive resources.

So, in a nutshell:

  • If you are doing a non-trivial app and you care about quality, strongly consider doing it natively in Objective-C.
  • Interface Builder is great for layout and setting properties on complex screens. Use it for that but do everything else programmatically. If you screens are simple, avoid it altogether.
  • Learn Objective-C 2.0 idioms and use them consistently.
  • Learn good memory management techniques and plan your app around memory intensive resources.