Tela-Web

Key #4: Develop fast

May 24th, 2006 ericdes

Hey! You’re always too slow! Sorry about that, I’m more talking to myself here! Anyway, if you feel the same way or don’t want to admit it, let me tell you first it’s not entirely your fault. If you’re a good software architect, you know (and apply?) the great teaching of writing clear code that is reusable, easy to debug, and so forth. Not a single book or lesson will teach you otherwise…

This is not for you! You, as a software creator, should sketch your applications rather than develop them. In your day to day programming, you’ll be faced to many choices. If you hesitate more than a couple of minutes of your time, you should decide on the easiest route. The implications are not easy to swallow. Lets review a few examples:

• You design a database. You could do the job with only a few tables but you know it won’t be easy to upgrade easily in a relational way if you later want to grow for a more elaborate model. My suggestion here is to not worry about future expectations of your software. Make it profitable first, it’ll be always time to improve and remanufacture your code later. The same reasonning applies here if you should take into account possible extensions for your objects, methods, etc. The answer is NO.
• The best language to develop your project is the one that doesn’t contradict the previous keys and will put your product on the market first. Normally you should choose among the languages you know the best and the ones that perform the requested tasks the easiest way. Forget about newer languages and the hype if you don’t need them NOW. Older languages also perform faster (not always though), which is not a bad thing. Whenever a RAD (Rapid Developement Tool) is available, use it to its full extend — I’m thinking here of database applications. Also components can speed up your developments tremendously. Use them instead of reinventing the wheel.
• “An N-tier design is the way to go”, “Develop once, deploy everywhere”, etc… As tempting as they are, those concepts also add a lot of overhead to your development. Unless your project will immediately benefit from them, I recommend you to stay away. Their idea is to ease a future development but that remains to be proved: I bet future development tools won’t be compatible and you’ll have to start from scratch anyway. I also bet you’re application will perform much slower, which could become a serious trouble to solve.

Entry Filed under: Keys to creating software (and making money...)