Probably Followed by the Hard Twenty
Because there are some questions what the API we’re programming against will look like, and about Model structure because of that, the team prioritized working on a section of the project that is mostly isolated from the API. One consequence of that is that the team started building out views and view controllers early, and are working without design right now.
Which means I get to look super productive because I’m doing basic data manipulation, and putting together the flow between views and not even thinking about styling. This means I’m throwing together entire workflows of screens in a day because putting a
UITableView on screen and throwing stock cells with labels in it for an array of data is easy.
It’s entirely possible I’ll be spending significantly more time later styling everything, making sure all the bits fit together smoothly, and generally polishing these screens than what it took to build them in the first place.
Another interesting side effect to spending so much time thinking in terms of raw functionality is I came up with slightly different than usual patterns for managing modally presented workflows for creating / editing data over multiple screens. The flow is executed as an operation, with a completion block that fires when the flow completes handling the data and removes any concept of presenting the workflow from the view controller that needs the data. This means that the implementation details like needing a navigation controller, or even a pre-populated navigation stack, are handled by the workflow manager rather than the presenting view controller. I may abstract these out another layer into the application router, but so far it’s a very promising start to minimizing the linkage between different view controllers in the project.
Reading a recent post on Red Queen Coder reminded me a recent, but very useful part of my lexicon of useful programming terms taught to me by Eric Slosser during a particularly stressful moment in a project: the “Rock Fetch.”
Imagine that someone asks you for a rock.
You bring them a rock, they ask for a bigger rock.
You bring a bigger rock, they ask for a rounder rock.
You bring a rounder rock of about the same size, they ask for a slightly smaller, less drab looking rock.
The cycle continues until the person asking is satisfied for reasons you don’t comprehend, you give up in despair at ever finding just the right rock, you get actual requirement on what the rock should be, or you get into a fight about rocks.
Giving me a series of rock fetches is a sure way to tank my motivation, because rather than getting to hit a flow where I’m solving a series of problems and moving along, I have to get the task close to what I think might be correct and then ask for input. This leads to me feeling micromanaged, and often mislead because as the requirements emerge it often means refactoring code to deal with new complications.
The best defense that I’ve found so far is to scrutinize tasks before starting them, and to get solid acceptance criteria before writing any code. Developing the instinct for what makes a task too vague is a challenge, especially as it’s a sliding scale for different phases of projects. At the beginning of a project, every detail needs to be specified somewhere because there aren’t similar examples to pull from. On the other hand, late in a project more vague
requirements may be plentiful because of the implied “that functions in a similar way to already implemented sections of the app.”
If there are good reasons for the task to be vague, such as needing to investigate several approaches, then I now try to break that task down into at least two phases. One for actually nailing down what the task will be, then a second for implementation.
I still make the mistake of committing to a “Rock Fetch” task from time to time, but I’m getting better at catching them early, and my sanity and morale have profited quite a bit from it.
Computer Vision Done Quick
Part of the joy of working on a brand new project is exploring just how much work it will be to solve new problems. One of the requested features is to build in a decent document scanner, to cut down on requiring users to send faxes of documentation.
After looking at some of the open source libraries for the sort of work on iOS, I decided to just implement a pair of CIDetectors to scan for rectangles and text, then see how the results came out. They’re not perfect, and there are some quirks that I’m working out, but the result are decent. With some good UI design to allow the user to adjust for minor skew and hopefully a few tricks to improve the quality of the results, I think that an optimized version of the out of the box solution will be good enough to ship with the first release.
I’m already collecting interesting ideas on just what I could do using OpenCV, and taking inspiration from some of the very cool work in the Dropbox document scanner to make an even better recognizer.
High Efficiency vs. High Drain.
I’m spectacularly bad at relaxing. My normal cool down time between getting home and being relaxed enough to sleep clocks in at around 3 hours at a minimum unless true exhaustion is involved. This involves a structured cool down, following some basic sleep hygiene, and guided meditation.
And while I’m spectacularly bad at it, I’m less spectacularly bad at it than I used to be. Getting into the habit of having a system that I trust to capture things that I need to get done, therefore getting them out of my head, has been absolutely invaluable.
The interesting twist is that one of the largest obstacles to me getting to sleep is a great asset most of the rest of the time. Having the ability to hold a lot of information in my head at once and quickly iterate through it is great when I’m trying to solve a problem, but it isn’t really great when I have a list of things that need doing grinding away at the back of my mind and I can’t help running through that list again and again.
Front-Loading Suffering vs Back-Loading Suffering
I’m on a team starting a new and exciting project at work, and hitting the “new project” button for a release that’s scheduled in the 4-5 months leads to a very interesting question: “Do we start the project in Swift 3?”
In two months (or so), this will be a foregone conclusion as Xcode 8 will be out of beta and Swift 3 will be in a released state. Right now, the question is a bit trickier, I’m not a huge fan of doing production work in beta software, but there’s a long term win in starting the code base in Swift 3, plus the core data code generation, among other tools, are likely to be a solid win for reducing turnaround time in our foundation code.
That needs to balance against potential lost effort until the beta ends due to higher than usual Xcode instability, potential feature churn, and churn within any external libraries waiting for Swift 3 ports.
I’m not 100% sold on either direction, and I’m not the only developer involved in decision, but I’ve been debating the pluses and minuses in my head in preparation for the debate that will be happening before we hit