Ethics and Disclaimers

This article specifically relates to work my consulting work.

Errors and Bugs

While I will try my best to write software that is 100% error free, I can't guarantee my software will be perfect. The code I write for you will probably have errors in it.

I prefer to cut a feature entirely than to miss a deadline. Often it's better to drop a feature that contains errors rather than taking another day to fix the error, if it means a deadline can be reached. I will discuss these situations with you if a particular error effects a shipping deadline.

Project Estimates

I will try to provide accurate estimates for how long a particular project will take, but accurate estimation is normally quite difficult on high value work. To create valuable software, it is necessary to make a lot of unique combinations of decisions about how to solve different problems. It's the uniqueness of the project that makes estimation hard; software that does not exist has, by definition, never been done before.

Estimates are not the equivalent of deadlines, but they can help set expectations about what can be delivered by a deadline. To meet deadlines, it's usually necessary to "ship early and ship often", so I will often insist that the team I work with meets with me on a frequent basis, preferably weekly, if not more frequently.

Maintainability

After a lot of software engineering, I am biased toward simplicity. I am suspicious of solutions that are unnecessarily complex or attempt to re-invent various wheels. I will make use of labor saving open source libraries where ever possible.

Software Security Vulnerabilities

I have a very good understanding of the principles of writing secure software. However, I am not a full time security expert. In every case that applies, I will use battle-tested software created by full time security and cryptography experts. I will also write defensive code that deals with all the common attack vectors on web applications, mobile applications, and APIs.

Software today is very reliant on third-party libraries. Those libraries may contain undiscovered security vulnerabilities, and this may still open your software up to attack in spite of my best efforts.

What I Won't Do

I have a number of projects I will flat out refuse to work on:

• I will not write software that violates the privacy of users.

• I will not clone an existing software product that has been created by a well known or well-funded competitor. Cloning is usually never successful (with some notable exceptions), but either way it is boring as hell to work on.

• I won't participate in a project that seeks to do weird proprietary things with open source software written by other people.

• I haven't seen a good proposal for a mobile game in a long time, so I generally no longer work on mobile games. However, I am open to working on genuinely new ideas.

This is not an exhaustive list!