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.

Friday, August 12, 2011

How to become a good programmer

Being a programmer isn't very easy. Of course learning one programming language is easy, but mastering it real good takes a lot of time and lot of problems to solve in that specific language. Learning next language if it is in the same paradigm is easier than the first one and so on.

If somebody is intelligent enough he or she could learn any new technology and any new language. It only takes time. I don't say that finding free time when you're working and / or studying at the same time is easy, but in our job we must learn at all the time. Languages, frameworks and patterns are evolving still.

If it comes to design patterns here it's identical situation - the only thing that matters is using them in practice. Only when we are doing something we encounter real life problems and we can solve them. Year by year problems to solve are much harder and harder. People are still searching solutions for the more difficult ones.

People say that good developer is when he tend to stay in deadlines. But in my opinion being a good programmer is being curious of how it's done inside in application. Because only if we knew what will be in memory and what computer must do if we do A or if we do B we can write effective applications. I know that when it comes to business time is very important, but for the cost of doing something well.

I've worked in company (I will not say name) in which everything was done in two ways:
- as fast as we can but doing dirty code
- as long as we could reapairing this dirty code made earlier
After some time I've noticed that 90% of programmers time can be spared bo doing something well once. So doing something well should be our goal from the start.

Todays languages are making programming lot easier - we don't need to worry about memory consuming and heavy weight of application. People will buy faster machines and / or client will buy bigger server - it's just not our problem they say.

Computer games today are being made using graphic tools and only a few scripts (of course there are some exceptions). If we look at demoscene we could find really cool graphics and really cool stuff which will run faster and look much better than games we can buy.

The difference is huge - the demos are from 4KB to 64 KB size only. And they look very nice and produce the best graphics possible at good performance - how could that happen? Because these small apps weren't done in stress of time and money - they were done by people who really enjoys what they are doing.

So in my opinion we should do something interesting for us or quit and find another job. Because only if we are doing something which is fun for us we would do it with enough passion and curiosity needed to do it well.

Thursday, August 11, 2011

Javascript: The Good Parts

In my projects I've encountered many problem involving doing something in JavaScript. First when I've came to problem when I needeed to use it I've searched the internet and found jQuery - which is very helpful. I copied it and it works! Really simple!

But later when I've stucked with some unknown for me problem and nobody could help me with that I've realized something is wrong. I knew really well object programming but here with this strange syntax I was helpless. Then I found this book:,jscmoc.htm

When I read the table of contents I realized what I was missing. After reading it I can now say that I understand what really JS is. Author definetely described solutions for my problems - and now it was clear for me what I was misunderstanding.

In all languages we can always solve one problem in multiple ways - it's up to us which way we preffer, but some ways are easier to do than others and some ways just produce cleaner code. JavaScript is a language in which beginner with experience from other objectives languages can do a huge amount of mistakes. Programming in JS is very tricky, but also very fun. You must ensure yourself that you're really know what you're doing and what's happening in the code before doing something real big.

Author explains typical anti-patterns and shows what dangers are waiting for us if we do something wrong.

So now, after reading this book and several talks with smarter than me I can say that there are very few people who know this language very good - but it's a shame, because I see some perspectives in it. Its popularity is growing really fast in the dev community.

To sum up I recommend this book to every developer.