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…