Business programming simply isn't that hard
Business programming simply isn't that hard, right?
Seriously, how hard can it be to wire a SQL database to some basic business rules ("employee HAS-A manager, employee.manager_id != employee.id
") and add some AJAXy goodness on top like edit_in_place
? Business applications are a simple pyramid with the frameworks doing the heavy lifting at the bottom and the AJAXy goodness on the top providing the sizzle that makes users say "wow." Right?
And needless to say, business applications are borrrring! Nothing about the programming is stimulating. It's all a question of managing requirements, priorities, and figuring out how to cram ninety hours worth of work into a seventy hour week to stave off the outsourcing.
But... Could there be interesting problems to seek out
in business? Try a couple of these on for size:Real time risk management
You have an online banking application. Your goal is to produce a system that can alert a customer service rep when suspicious activity
is detected so that they can telephone the customer before the customer has left the web site. How can you detect suspicious activities in real time?
For an example of how this works, consider credit cards. I often make very large computer purchases, and they never bat an eyelash. But when I purchase jewelry
for my wife, I get a call. A friend swears she gets the same pattern, but they called her when she purchased an iPod
because she doesn't usually purchase electronics.
Your system will notice weird patterns, like a customer who never banks internationally suddenly trying to transfer money to Russia. But take heed: you don't want to be bothering the fur importer who regularly does business in the "Wild Wild East." You need to look for suspicious
patterns. And you need to explain it simply enough that a customer service rep knows how to verify the transaction with the customer.
Did I meantion in real time
? Visa normally calls me within a few hours. Your goal is to make the call while the customer is still on line
.Let's get our hands dirtyConcrete
is funny stuff. From the moment you start mixing it, you have a limited amount of time it can sit in the mixer truck before it has to get poured. Construction sites need so much an hour, no more and no less. A cement company can't send a customer one hundred trucks simultaneously and have them idling on site, they have to arrive just as they're needed.
In major cities, traffic
is a problem. So build a system that can dispatch and direct the trucks in real time. Your input will be demand from customers plus real time traffic and road construction reports, which your system will use to update a graph representation of the road network. Naturally, it will search the network in real time for apropriate paths
for the trucks. They're outfitted with GPS units, so you will have real time locations for your trucks.
Don't forget to manage the return of the empty trucks to your site. Concrete is a low margin business, so operational efficiency is a competitive advantage
. Do a great job, and your company could become the dominant supplier.update
: This isn't just finding the fastest way to get trucks to their destinations. That is not a simple problem, but you must also solve the flow problem: when do the trucks have to leave your yard in order to arrive at each customer's site on schedule? If a customer is ninety minutes away and traffic is building towards ruch hour, you have to leave earlier. How much earlier? Do you send two trucks by different paths at certain times and reroute one of the trucks if the other arrives ahead of schedule? When an accident suddenly clogs the freeway, is your system able to predict how long the freeway will be closed and what the effects will be on alternate routes?
To do this job well, you're going to have to have a really good model of traffic in the city you serve. Don't forget to build the baseball, football, hockey, and basketball schedules into your system, along with big ticket concerts :-)
...his lips are moving, that's how
Consider any large organization that makes big-ticket sales to walk-in prospects. Let's choose car sales. Some prospects will walk in and buy right away, others will never buy. Some will buy, but only if you follow up with a call after they've been in for a test drive.
When's the right time to call them back? If salespeople call too soon, they waste time, make the prospects feel pressured, and their quote ends up being fodder for the competition to beat and steal the business. But of they call too late, the prospect will have bought from someone else.
Build a system that learns over time when to call each prospect. For starters, you'll have access to a survey team that will call a sample of prospects that didn't buy. They will fill out a form about the prospect (age, gender, household income, zip code, car they owned, car they bought, anything else you can gather), along with when they bought.
This becomes your training corpus. Now build a system that the salespeople use to manage callbacks. Your system must suggest when to call the prospect in order to have the best chance of closing the deal.
Yes, your system must be able to train itself. Yes, your system must do "meta-training": if the zip code isn't significant but the age of their existing car is significant, your system must recommend dropping the former from the survey and promoting the latter to the top of the form. And you ought to add new questions from time to time and test them for relevance.
Oh yes, you'll have to infer distributions like the Erlang
, or Binomial
for purchase times: it should figure out the most appropriate model for lag between test drive and purchase.
Did I mention the scale? This system should be rolled out to every dealer in North America, and every salesperson on duty will be using it. How many dealers are there? I think you answered that question in your job interview, didn't you?Well?
Does business programming have to suck