Get a Highly Specialized Engineering Job

I recently found myself reading this article Get a Tuenti Engineering Job. I felt specially identified with this part:

"lot of the skills we look for, while taught at top universities, aren’t used that commonly in work at many European companies"

There is no doubt, Tuenti is right. In order to keep our programming skills as sharp as they should be consider programming contest training.  Following my own advice I´ve just signed up for this web site: http://www.betterprogrammer.com/ .

I´m going to practice one of this problems or similar 15 or 20 minutes per day, but I am also going to give it a little twist. I will use C/C++ or Python to make of it a richer exercise.

Introduction to Drools

Motivated by my soon to begin MBA studies (Sept 28th, I´m so happy about it) and my almost repulsive feeling towards developing "end-user oriented" Web applications without any interesting business logic behind, I am more than decided to get out of the sterile web development business and get into the BPM world. I am expecting to see that  happen before 2012, hopefully...fingers crossed.

That said, I've reading about Drools lately  and it seems pretty interesting. Keep reading.

This is an extract of the article An Introduction to the Drools Project By N. Alex Rupp

"Why use a rules engine?

The business world is full of cliches about change, how everything changes, how change is the only thing you can depend on. In the technical world, this isn't exactly the case. We've been collectively trying to solve the same set of problems in software for thirty years--sometimes more. In the last decade, IT folks have been inundated with literature about rapid/extreme/agile development ideologies that stress the importance of flexibility and change.

But business needs often change faster than development teams, their processes and the technologies they rely on can keep up. We're getting better at it, but business tacticians still find themselves crippled as they try to realign their IT departments to support the shifting needs of their business. There's a lot of friction and frustration involved in this process.

Lost in Translation

As smart as IT personnel are, they are susceptible to the "telephone" effect. IT efforts often add as much friction to the execution of a business plan as they do value. Unfortunately, by the time the development teams fully understand the rules which govern decision-making in the business and are able to capture that decision making power in software code, the rules have changed. The software is obsolete before it has even reached the market and it needs to be refactored to support the new requirements. If you're a developer, you know what I'm talking about--we call this aspect of the development cycle "feature creep". Very few things are as frustrating to developers as having to build a system on shifting soil. As a software developer, you often have to know as much about the business as the executives do--sometimes more.

Imagine for a moment that you're a business leader. Your company's success often hinges on your ability to notice changing conditions in the market and figure out a way to take advantage of the new environment before your competitors catch on. Every day you have access to more and better information about your market, but it might not matter. Bold and clever insights and the "information advantage" can easily be squandered in the 6-9 months it might take to complete a development cycle for a new product. And when the product ships, chances are it's either feature-light, over budget, past due or some combination of the three.

To make matters worse, at the end of the development lifecycle, the market conditions could be fundamentally different than they were when the project was concieved. Now you're forced to comply with new legislation, you've lost your marginal advantage, and three of the five people who designed your software system have left the company--or worse--HQ is moving the entire department overseas. You're going to need to explain the complexities of the business to people who might not share your native language. If things don't work out, you could easily find yourself straddled with a poorly documented legacy application that you don't understand, that doesn't address your immediate business needs, and all the while orders are coming down from on high to "leverage existing assets".

Where did your strategy break down? Where are the places you might have done better? Recent literature onextreme programming, agile development and other lightweight processes stress the importance of automated unit testing and feature prioritization. There are other principles your developers are familiar with, which can help them respond to your changing needs and shorten turnaround time for their porjects. Most of these principles, like system decomposition, have been around for decades and are aided by up-and-coming additions to the Java platform (like the Java Management Extensions library). Many of these principles, like Object-Orientation and Role modeling, are built right into the Java language.

But Java's still a pretty young language, and the Java platform is by no means complete. One technique that's gaining traction in the Java community is to separate the business decisions of your executives from thetechnical decisions of your developers, and to keep those business decisions in a central data store, where they can be managed and altered in real-time (that is, business-time). It's one strategy you might consider.

Why should your development team have to capture in code the subtle and complex rules that guide your decision making as a business executive? How can you convey the subtleties of your reasoning to them? If so, is it prudent? Probably not. Something might be lost in translation, like the bottom line. Why take the risk that the logic governing your decisions (the executive logic) will be misrepresented in the application code or even in the testing code? If it is, how would you verify that--would you learn to program and write all the unit tests yourself, or would your customers test the software for you? It's hard to keep one eye on the markets and the other in the software code.

It makes more sense that these rules should be centrally located in a place where you can manage them directly, in an intuitive format that you can easily understand, instead of scattered throughout the application in software code where you can't get at them. If you can keep the executive logic out of your software and trust your developers to make the right technical decisions, you will notice the difference. Your project lifecycles will be shorter, and your software will be more adaptable to the needs of your business. Instead of trying to steer the titanic, you'll feel like you're in a tri-hull racing cat."

We are Traders!

We are Traders, well right now not really, but soon enough ;)