Stable developers carefully work to mitigate failure, however distant or improbable it might be.
At the end of 2015 our product development team decided to set a goal to build a polished app in one week’s time in order to grow our portfolio and challenge our technical abilities. We also decided to design the UX ourselves, and then seek the opinion of one of our most trusted UX partners, which enabled us to gain more firsthand experience understanding and managing UX decisions in this week-long challenge. We ended up exceeding our goal by building a working prototype in about four days, but after showing the app to our UX designer, she identified opportunities to significantly improve the UX. Realizing that we could launch a better product, we decided to pivot. While pivoting is widely known for being a very painful process for development, pivoting in this case was not a painful process, because we wrote the code to be extremely flexible from the onset. More specifically, one of the most significant pieces of the functionality used Swift generics to populate every list of data. Even though her new designs looked and functioned completely different (including an entirely new UX and underlying model), techniques like using Swift generics enabled us to successfully change direction and finish the new version less than a week after completing the initial prototype. Using Stable development techniques is important to being a Stable consultant.Design Before:
Design After:
Stable developers tend to generate a lot of process because they know process creates predictably and measurability.
Let me begin by saying that every single project will involve edge cases, which are situations that can be handled in more than one logical way. A quintessential example of an edge case is a tiebreak in a sports game: while the concept of a tiebreak may at first seem like a simple problem, take a moment to think about how many sports handle tiebreaks differently. The NFL for example has 5 different types of tiebreaking procedures. Or in the MLS, tied soccer games go first to two 15 minute extra periods of time and then penalty kicks, and even then both teams can still tie. These examples highlight how edge cases can balloon in complexity, yet are critical components of development which must be handled properly in order to produce a good user experience. It’s also important to note that edge cases can arise during any stage of development, which means that they can become increasingly difficult to deal with and require more time. As stable consultants, we seek to prevent extra work by first identifying edge cases as soon as possible, even as early as our client discovery meetings, and second handling unforeseen edge cases by defining processes around eliminating ambiguity, like creating edge case decision trees. While edge cases can become very complex, here is an example of a simple one from this app pictured below: what would you expect to happen if the “Done” button was pressed while the cell has no title?
- The cell would be left empty and without a title
- The “Done” button would be disabled until there was a valid title in the text field that has focus
- The cell that’s being edited automatically gets “untitled” assigned as a title
Stable developers understand how to ask the right questions, manage discussions and translate needs into project scope in order to build quality products.
When discussing projects with clients, our first step is taking the time necessary to ensure that both we and the client fully understand the project needs and expectations before providing a quote. In turn, this enables us to provide a proper estimate of the project scope and preempt issues that could arise during development if not accounted for, and jeopardize deadlines. This characteristic of Stable consulting also provides us increased versatility in working with different types of clients – from the savvy who have a fully baked app plan, to people with minimal technical knowledge. For example, if our client is very specific in what she or he wants, then we’ll provide technical guidance where we see opportunities to leverage our experience. On the other hand, if a client has a vaguer idea of what she or he wants, then our role will become one of an involved expert, providing our client with several options and helping them determine the best direction. Additionally, we take the time to properly research project feasibility, from APIs (connecting your app to 3rd parties like Facebook), to limitations placed by app platforms (for example, Apple does not allow playing a notification sound for longer than 30 seconds while the app is inactive). Over time we have learned that having open discussions on both project scope and edge cases as early as possible is key to bringing people onto the same page. Disambiguation of features and scope significantly helps us build a quality product that do justice to our clients’ product visions, and also helps our clients to better understand the user experience design and app development processes. As Stable consultants, we won’t move forward until an accurate and proper project direction is established, which is a small short-term action that is key to reducing extra costs, changes, and other issues in the long-term.Becoming Better Stable Consultants
One caveat of Stable development, which underlies our label of Stable consultants is that Stable developers are not known for being as quick at building apps as Volatile developers. For example, instead of refactoring (when you reorganize and adjust code to be more flexible and less brittle), Volatiles will simply add more code. Although that may be ideal for prototyping an app to test the viability of an idea, it is not ideal for building quality apps, as the trade offs to building an app faster, such as cutting corners or not properly architecting the app’s codebase can lead to long-term issues in the product. Building clean code, which is the outcome of stable development, does take longer – there’s no way around it; but it’s what makes a quality product that will outlast one built without sustainability in mind. On that note, there are some practical techniques that developers can use to become better (faster) stable developers; here are a few techniques we regularly use to save time when writing code:- Shortcuts for EVERYTHING – this saves more time than one would guess by making micro improvements in day-to-day work that snowball into huge gains over the lifetime of a project.
- Fabric for beta testing (with Crashlytics) – this will allow you to get an app in the hands of a group of beta testers quicker and easier than Apple’s default method (TestFlight), and will also gather situational information when the app crashes on a user’s device, which is necessary to fix bugs and would otherwise take more time and effort to gather and understand.
- Reveal for debugging view/hierarchy related issues – these types of issues are known for being inherently frustrating time consumers. When there are probably more important issues at hand, a tool like this will help developers spend less time on layout-related UI bugs, and more time on features, performance enhancements, and stability.