CORE VALUES - Engineering

  1. There's no such thing as too much up front design

    2. Not in my experience, at least. I have found that design needs to be considered eventually, and making changes in design is a lot cheaper when it involves using an eraser instead of a debugger. In fact, I have noticed that those projects in which I have been most efficient in the past are precisely the ones in which I have spent an unusually long amount of time in the design and research phase. Coincidence? Probably not.

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

    3. 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?

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

    4. When testing a product, try to test cases well 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
    For example, let's say I am working on a chess game. I would most definitely not limit my testing to an 8x8 board with the usual configurations of pieces. I may want to experiment on a small 4x4 board if I am concerned with testing the end game or stalemates. Or maybe I'll use a board with only pawns to test pawn movement ( hmm, I wonder if the game and AI can handle the situation where there are no kings on the board? ). Or I could try an empty board to see if I can get the game to crash. Or I could delete some important board configuration data or set up a board with -1 rows to ensure that when it crashes, it does so gracefully. The possibilities are endless.

  4. Quality Assurance is an engineering job

    5. An engineer's code relates to a well prepared end product in the same way ingredients relate to a well prepared meal. It is nearly impossible to create a high quality meal with poor ingredients, no matter how many cooks, taste testers, and customer surveys we factor into the process. Besides, it takes less resources to fix a bug during engineering than it does to delegate the bug between engineering and QA and get back to fixing it later, when the feature that the bug relates to is no longer fresh in the engineer's mind and he needs to interrupt his current task to fix it.

  5. A good contractor works WITH the client, not FOR him

    6. In software engineering, people often assume that a client's job is to give orders and a contractor's job is to follow them. I disagree. I think a good contractor is one who not only has a thorough understanding of design and engineering best practices, but also communicates them clearly to others and takes a stand for implementing them. There are many reasons for this. It is quite possible that the client does not spend half his life reading about development techniques and design guidelines and simply does not know what the designer or engineer knows. Also, following best practices leads to a better end product, which is mainly in the client and customer's best interest. Finally, a contractor has a personal stake in the end product as well - the contractor's name and reputation and time are involved in the product as well asl the client's. Yes, the client usually has the final say, but that does not mean that a contractor should behave as an unthinking yes-man.

  6. Excessive overtime is nothing to brag about

    7. Usually excessive overtime is a sign of unrealistic planning, inefficient work, or both. Finishing a task under budget and ahead of schedule while working a 40 hour week, now that would be something to brag about! Surely someone who can do this is much more efficient, reliable, and focused than one who performs the same work in a 60 hour week, right?

back to core values