Today’s Habit is brought to you by the letter “R” and the number 1.
Seven Habits of Highly Dysfunctional Enterprise Developers:
- Blame Everyone But Yourself
- Confuse Motion With Action
- Use Complexity To Demonstrate Intelligence
- Keep Important Information Secret And Safe
- Fix It Later
- Reuse Is Overrated
- Principles Are More Important Than Results
Feeling that urge to rewrite qsort? Convinced you can write a better Hibernate than Hibernate? Positive that there is no XML parser out there that will suffice for your project? Um. Put down that Erlang compiler a sec and listen.
I completely understand why these urges come up. We love to solve problems. And sometimes, writing a billing application isn’t nearly as fun as say, creating a custom persistence layer that converts XML to binary ZIP and inserts it into a BLOB in the database. But you won’t get a promotion because you reinvented the GOTO in your custom Haskell extension. You might get a promotion because you shipped a working product on time, under budget that delighted your customers.
The goal of every software project is to launch. Anything that gets you to launch quicker is good. Previously developed libraries, even beta-grade ones, can be a win for you and your team. That’s not to say you should create a Frankenapp by bolting every Open Source project together within reach. But making judicious use of the right technologies can substantially reduce your time to market.
The one (and I do mean ONE exception) is creating something that is part of your core competency. If you’re Intuit, then accounting software is your core competency and you’d better write some cool 401(k) prediction algorithms to help people use Quicken more effectively. But what about a web framework? Intuit isn’t in the business of creating frameworks. Should they write a brand new one? Probably not. Understand what you’re in the business of doing, and write THAT. Find help for everything else, as much as you can.