Thursday, August 25, 2011

Worse is better

Recently I've came across lot of development problems which every developer is finding is his or her normal work. Every time I was facing any design problem I'd had two options. First option - design it in a good way, taking in account future development of this software. In opposite we always can write something in a rude bad way, but few times faster.

And I have to say that it's very difficult question which way choose - because we will be doing something that nobody can ever see inside (I'm not counting any future developers of our system). So if it's worth doing it at our's best? Yes indeed it's worth spending some time if we'll be developing our system for couple of years, but if something is working identically why not to choose the shortest way to do it?

I'll be punished for what I say... take an MVC architecture for example. It's common knowledge what is it for - to separate model classes from views and from logic. The main reason of this separation is to keep eventually changes simple - and I agree with it, but come on - do you know anybody who ever switched to another database in project? Or changed view / templating engine? It's rather rare situation but now everybody wants to have this possibility. I think it's mostly to being cool. We can say - oh I can switch my db to another one and my website will still be working! In the meantime this website could be doing much more efficiently. Because if we are on some abstract level to be compatible with every db solution we're just loosing advantages which are given to us from the very specific db engine for example. Because if we use some specific options from one db engine changing it to another one is again more complicated. And we're in the same point with code that is rather blocking us but in fact we've chosen it to not being blocked by anything.

It's very funny in my opinion, and we should always consider our choices before we can start. And I don't blame MVC pattern - it's the best pattern to build websites and such. Only thing I blame is bad software management and bad planning.

So returning to the main point it's not always worth to do something the best possible way - it's rather to sustain project requirements as fast as possible. Because from the business point it's better to deliver something fast rather than working with something for couple of years and deliver the same product little easier to develop in future - if our competition deliver something earlier future development of our idea won't even exist.

So my point is if we're doing something - I don't know a website or even a desktop software we must focus on our requirements, and not doing something the best possible way. But in the other hand we must be careful enough and try to deliver solution that is fullfilling our all requirements.

So good requirements and good business plan is everything we need to deliver best IT solutions.


  1. We can agree that requirements are major.

    I think that programming style depends on developer practice and learned behaviors. Well created code shouldn't cost us more resources than ugly one.

    It should be made in the best possible way, but not in the most expensive.

  2. Yes, you're right. The more experienced developer is the better code he/she'll produce in the same amount of time. So gaining experience in software development is all about creating better solutions in smaller amount of time.