Recently, i've been discussing things with a friend of mine who's feeling more than a little frustrated. i completely understand his pain, and have been trying my best to help out, but ultimately, his frustration boils down to "Big Things Don't Act Like Little Things". (True of a great many things, but that's beside the point.)
With small operations, there aren't a lot of dependencies. So it's easy for a small team to make choices like "Let's use Erlang to tie together a bunch of Tahoe systems connected via an XMPP stream to flemmox the hoosibanger." Feel free to substitute your own words (made up or real) for whatever part of that you don't understand, but generally it boils down to the fact that with a small team of folks, you can generally head off in whatever direction you like and not worry about it. If it works, great! If not, tear it all down and start all over. It's all part of the game.
Things get a bit more complicated with the increasing number of individuals involved with a given project. You suddenly go from having zero systems to tie into to dozens or hundreds. Granted, if they're built right, they all expose data access points, but that's not always going to be the case, so there's additional considerations for security, and load balancing. Plus, you have to figure that someone has to coordinate all that stuff, plus train the folks doing operations how to work with it (don't forget, if you're doing anything financial you've got SOX accounting and requirements to consider) in addition to making sure that systems are kept up-to-date and have the latest security patches in place so that the insurance auditors are happy. Oh yeah, and then there's the whole issue about retroactively including system wide optimizations for data processing and Content Distribution Networks, and… well, you get the idea.
So, yeah, there's a pretty good reason why big companies (particularly REALLY big companies) tend to focus on a fairly standardized set of tools and resist new technologies as much as possible. It's one of the reasons that acquisitions generally don't meld into the borg quite as easily as folks sometimes imagine them to.
That's not to say that small projects aren't free to run off and do their own thing many times. It's just that they need to realize that they are:
- on their own.
- damn well better have more statistics and measurements to prove substantial cost benefit of being on their own.
- Better be willing to provide #2 at a moment's notice because Internal Support is going to battle you like no tomorrow.
Why are they going to fight you? It's their job. They're supposed to do that.
Their job is to make sure that things are "normalized" so that when there's a big fix introduced, or some new system rolled out, everything in the company can use it right now. Having your system out means that they can only guarantee the number crunchers less than 100% for any improvement they can make.
Granted, 80-90% of most startups seem to have a final business plan of "be acquired" so i'm not really faulting them.
Save This Page
