The process of building an application

I have been a freelancer for the best part of a decade now, writing code for whoever wants to hire me, usually choosing interesting projects for me, rather than public visibility.

Over the years, I have tried several methods to incrementally go from the concept to the end product, and I must say that’s usually a thorn in my side.

Basically, what’s good on paper is this:
– Decide on the specifications
– Design a UI, from a technical and an ergonomic standpoint
– Build a working prototype with all the major bricks in place, and pretty much everything working under the hood
– Tune the prototype’s UI to match the desired one
– Fix the engine parts
– Make the minor UI adjustments that are necessary
– repeat the two last steps a few times

The iPhone has kind of changed that. Since it’s UI centric and not functionality centric, every “minor” change in appearance (or more correctly in transitions, view controllers and UI updates from the backend changes) can trigger a massive rewrite of the engine.

Basically I find myself more and more reverting to stuff I tell my students NOT to do : having global variables, putting all the information in the same object that’s shared over the application, having the same code but for a couple of variables replicated in many places, and changing the behavior of my application based on the class of the untyped parameter I used in the function.

Everything’s not bleak, of course, but as soon as you hit the boundaries of what the guidelines and Apple’s developer tools suggest as good UI, you’re on your own.

At the moment, my usual development cycle is broken. Most of the “small” modification take about the same time as big ones. It’s not about changing the color of a button anymore, it’s about propagating the information back and forth to the whole. And then changing to color of the button.

Just a few days ago, I was discussing Agile with an ex-student of mine. There’s quite a few semi-formal methods to organize a development team out there, but most of them have the incremental “feature request / bug fix” cycle in at the end. I’m just trying to minimize the impact of that cycle in the last stages of the development. Agile, or its “competitors” provide some sorts of guidelines for the initial stages, but in the end we always have to face that “tuning” process.

I wonder if the variety of frameworks and languages and platforms out there, with their own sets of rules and tools, might not benefit from some kind of optimization on that last part, or if there’s a way for developers to come up with a decent solution to that universal problem. Right now, every time I switch environments, I have to design my apps and my development cycle slightly differently. And it’s very time consuming.

What was that joke again? the last 10% of the application development takes more time than the rest of it together…



  1. Hi,
    It is strange that I never feel this sensation of a strong interaction from the UI side to the application kernel code.
    Perhaps this is due to a different education in my work : Always make two different layers in my codes :
    – The UI and all the methods (access, data implementation, comportment etc…).
    – The kernel code and the methods needed for any interaction from any code.
    This separation makes easy to modify or/and improve the one or the other. I mean a true separation, for example two dlls with a Windows based applications. I don’t know if it can help, but I feel it natural making a separation between those two objects.

    I hope I’ve been enough clear.

  2. Yes, I might have been unclear as well.
    I wasn’t implying that UI and data are inter-dependant. MVC still is the rule.
    But the way the UIViewController works, there is a lot of data (as in UI cross variables and references to data) shared or moved along the view hierarchy.

    The data side doesn’t change with each interaction, but a change in the logic of the UI changes a lot of code, in the UI layer. In the MVC, you’re supposed to have a reasonable balance between the Model, the View and the Controller.
    Here, the view code is rather limited (if you use Apple’s controls, which is preferable), but the controller code is just huge. A change in the view or in the UI logic changes a lot of code in the “engine”, the controller.

  3. Ok, I think is clearer now.
    Did you heard that Apple argues that we must give more time in UI conception because this is the best part for an Application to succeed. It appears now that this is a hard problem to manage during life cycle Application.
    Sometimes I ask myself if it could be interesting to include a Design training for all developers.

  4. Yes, and no. The major problem with the front end part is that it’s highly subjective. Today, I like blue steely colors. In a year, who knows? And who can argue that Ferrari red is a better or a worse choice?
    Ergonomy has a lot to say about optimal button placements, about the number of clicks you should have to get a certain result, and that kind of thing. These are all valid and objective points programmers should learn about (me included, but I’m just too lazy, I guess).
    Common sense also gives you a salient point to build upon.
    But design is a matter of tastes, and function, and opportunities. It changes with every one of these factors… Suppose you have designed your interface with 3 buttons. You need to add a 4th, but there’s no room. You’ll have to design something else, probably based on what you have but still different.
    The point I was trying to make here was that this should not be too difficult, and it sometimes is way too much work for such a small endeavor.

  5. Don’t you think the CSS technology resolves a part of this problem on the web?

  6. I don’t know enough about CSS’s real scope and limitations, but yea, that’s kind of what I’m hoping at some point with desktop / mobile applications : changing a few lines in the css changes the whole appearance of the web page with minimum impact on the way the page is actually built.
    Interface Builder is a great tool, because it goes in that direction. We all made modifications to the nibs of applications for which we didn’t have the source code at one point or another.
    On the iPhone, though, there’s only a minimal amount of things that are affected by the xib/nib. A lot of the mechanisms are still in the code section of your project, like any custom cell in a table view, the way your controllers are linked together, transitions between them, etc.

Leave a Reply