Don't fall in love with frameworks

The javascript world is on fire!
You've got tens of frameworks, all made to enable making javascript and web development easy.
angular, backbone, less, _, GWT, wicket, the old and established extjs, prototype, yui, and jquery (To name a few) have become common names among developers.

Some frameworks are meant to make your life easier with dom traversing and manipulation and encapsulate javascript features (jQuery, prototype), some add UI functionality (extjs, yui), while others offer full application frameworks.

However, these frameworks come with a price.

Once you bind your application to a framework, it's very hard to get rid of it. It's very hard to change parts of your application, once your web application is fitted with the paradigm of a framework.
Binding UI to model is another problem - Some of these frameworks bind data to UI components.

While this makes your initial development easy, once your application surpasses some volume and features, programmers tend to break this model (Something which is quite easy with javascript).

Binding is also very hard to debug - Sometimes you'll get an impossible to understand and follow call stack, especially with frameworks which bind model to UI components via events.

Another reason is performance: If all you want is a 3 page application which loads json objects, parses them and presents them on screen, using a full fledged MVP framework is a little bit of an overhead.

... And now, for the worst part.
You've written a nice widget/ control/ viewer/ whatever.
Now someone wants that object in his legacy system.
It's very hard to integrate binded code.
You tell him you can't.
He asks you why did you use the framework, if your code isn't recyclable.
You say 'it is, but you need to rewrite your whole client'.
CTO approaches you with angry eyes.

The rest - You know.

So next time you consider using a flashy, 'easy' to use framework, please ask yourself these questions:
- Will you need to reuse this code somewhere else?
- How much overhead will the framework add? Is it really necessary?
- How intrusive is that framework, in case you want to replace it?
- How much time would it take your team to develop the features you need from the framework? Don't add a full fledged framework for the sake of a neat button!
- How cryptic is the code? (Angular.js is a good example - Great framework, but you need to go all the way with it in order for you to enjoy its advantages.)
- How easy is it to debug? I know some of them are really, really hard.
And, finally:
In 6 months from now, will it bring value to your system, or will you need a month of knowledge transfer just to get someone new to write features into your app.

Be responsible - Use new technology that brings value, not heartbreak...

Want to get rich by creating a killer app?

Well, you most likely won't.
There aren't many companies making direct money from selling app in either iOS or android devices.

Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.

While no small change, this isn't exactly retirement money.

However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.

Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.

The others are losing their (Or other people's) money.

But now let's think of a different strategy:
Make it free, and earn from... well... um...

Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.

So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.

;-)

The importance of hackathons

Hackathons have become common practice of many companies.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.

Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).

A hackathon brings back the joy of coding and creation to such people.

A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.

I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.

Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.