CORE VALUES - Engineering

  1. User experience drives design and engineering

    2. Designers and engineers should be expected to jump over hurdles to create a smooth and efficient experience for their end users. End users, however, should not be expected to jump over hurdles to fit into the way the backend database, file system, company processes, etc, happen to currently be set up.

    Engineers may toil for a long time over a small detail. But when a product has thousands or millions of regular users, the amount of time spent on this detail will pale in comparison to the amount of time it saves end users. When Google optimizes performance, they famously calculate the total amount of time saved in terms of human lives.

    Example

    When I developed SylvanSync, and iPad app that helps teachers teach students, I started with an offline proof of concept that used demo data. Then I designed an unusually fast web service architecture that matched the flow of the application, sending the iPad only the data it needs, only when it needs it. When the flow of the application changed, so did the backend architecture.

  2. Domain knowledge is at least as important as technical knowledge

    3. The first half of a successful project is having strong design, engineering, testing, etc. The second half is having strong domain knowledge.

    Domain knowledge is knowledge about the environment in which your product is used, including but not limited to being an expert in the product you are developing. In the context of an educational app, active teachers and students will likely have the best domain knowledge, while in the context of a health app, doctors and nurses would be a good source of domain knowledge.

    Examples

    Before I designed SylvanSync, I visited learning centers to interview teachers and center administrators. I then designed the app based on what I learned, optimizing for the most common tasks teachers perform and the most common seating arrangements used in learning centers.

    When I started working at Blackboard, my first initiative was to become an expert on the web app that teachers use to interface with our mobile app. Among other things, I created a test course that systematically lists exactly one example for each of hundreds of different course content types, grading scenarios, rich text contents, discussion forum formats, etc.

  3. A feature is not done when it passes its test cases

    4. Passing your test cases just means that a feature is not broken, the equivalent of a D- in a school grading system. Some other factors to consider to move toward an A+ quality implementation may be:

    • Is there proper error handling and user feedback?
    • How good are performance and memory usage?
    • Is the code easy to understand, debug, and maintain?
    • Does the solution scale up to future requirements?
    • How polished does the end result appear to the user? Did his jaw drop to the floor?

    Examples

    With SylvanSync, I created a complex mathematical curve fitting algorithm to simulate natural handwriting, added left handed support to a scroll bar, innovated a safe and extremely efficient grading mechanism, and generally created features that far exceeded minimum requirements.

    In all my apps, I strive for a fluid lag-free user experience. If using fast algorithms is insufficient, I use multithreading to increase responsiveness. If that is insifficient, I use animations to hide delays and make them look intentional. Activity indicators and progress bars are my last resort.

  4. Don't just think outside of the box, test outside of it

    5. When testing a product, test cases outside of what is expected. There are many reasons for this:

    • There's no such thing as a scenario that can never happen
    • Unusual test environments can expose special cases that would otherwise be very difficult to encounter
    • Often an unusual test case can reveal a bug that can affect normal operation in a subtle way
    • Specialized tests can speed up debugging by focusing only on the problem at hand

    Examples

    In ZipTunes, an MP3 player app, I created functionality to read simulated music libraries under my control, not just your current iPod library. This way, I could easily test 10,000+ song libraries, titles with foreign characters, songs with missing information, umlaut/diacritic invariance, numeric sorting, etc.

    In SylvanSync, I made functionality to load lesson plans from text files instead of from a real data server. This enabled me to test malformed data and data that is difficult or impossible to generate from a real server. The feature had many other side benefits as well. For example, imagine Marketing's surprise when they asked for offline functionality for demoing, and I was able to accomodate easily.

  5. Software Engineering is the opposite of factory work

    6. Factories maximize output by hiring many workers at minimum cost. Software companies maximize output by attracting top talent.

    Products become easier to assemble the more pieces are in place. Software becomes more difficult.

    Factory work takes a predictable amount of time to complete. Software Engineering results are notoriously difficult to predict, for the same reasons that Research and Development results are.

    Factories rise or fall based on the efficiency of complex systems and processes. Software companies rise or fall based on the skill and ingenuity of their workers.

    etc

back to core values