I am a software architect from Albany, New York (yes we do software here). Currently employed full time at CommerceHub (yes we are probably hiring). Resume available here, but I’m likely not interested anyway.
Follow my nonsense on twitter at @datamiller
Request custom nonsense via email.
Corporate nonsense can be found on LinkedIn.
My philosophy on software:
- All technology is crap. All that matters is getting the job done.
- Development is never “finished” so much as “stopped.” You are always one month away from “done.” If you don’t learn to live with Good Enough, working in software will drive you crazy.
- Integration is king. The ideal software package is one you never even realize is there.
- Saying no to the inessential is how you deliver successfully.
- Understanding the problem is more important than understanding the requirements. If meeting the requirements does not solve the problem, to do so is unethical even as it is contractually correct.
- The correct language/API/tool/pattern is the one your team understands. If your team understands the wrong tool, you need to help them understand the why and the how of a correct one.
- Small is beautiful. Clean is beautiful. But any solution that meets the requirements is correct. Don’t get too hung up on the beauty of a working app; go build something else and make THAT beautfiul.
- More and greater defects were created from well intentioned cleverness than were ever created out of accidental ignorance. Embrace apparent stupidity. You’ll be more successful, and you can hire cheaper.
- Agile, Lean, whatever. To paraphrase Taoism: The process that can be named is not the eternal process. If you aren’t building your process to the restrictions of your people, machines and external customers with minimal dogmatism and maximum expectations of responsibility, you’re doing software wrong.
- Never counter an acute problem with a policy. A policy is an attempt to forego a potential problem by creating an actual annoyance. If you don’t have a chronic, concrete requirement for creating a policy, don’t create one. You’re just being officious and likely preventing progress.
- Don’t pre-optimize. Write algorithms clean first, with good tests. This includes not pre-streamlining the API. Write just the methods and classes you need at first, you can always add syntactic sugar later.
- Definitely do optimize, though, and definitely prior to release. Be guided by science! Load test, stress test, profile your slow/broken functions and fix what’s slow. Minimize work done inside transactions and other blocking structures through pipelining, liberal use of optimistic application transactions and the Saga pattern.
- Not all technical debt needs to be paid, but debt that prevents refactoring of high change rate systems or creates untoward operational instability should be addressed quickly. Continued development in a broken system spins cobwebs.
- All software should start with a release date in mind, and should be completed as close to the release date as possible. This diminishes the integration decay that software naturally undergoes in a concurrent development shop when “sitting on the shelf.” This means either releasing immediately upon completion of QA, or holding off on starting development until the last minute. When it comes to integration, procrastination (w/r/t inception of a project) can pay dividends in terms of quality.