Wednesday, November 28, 2007

Hijacking Cote's blog and running with scissors in the Oracle stairs.

I agree with Warren. I've delved long and deep in the bowels of company code (call the rescue team!) and I can tell you that while Mr Anderson (RTFA) is right at the 100,000 feet level, he's positively wrong at trench level. The problem is not that applications are built as black monoliths, a fact that Jesper Anderson concedes to as he states that this was the best approach given the available technology. No, in fact the problem is that there is a "process of programming" that has congealed over IT departments and that it is this process, this for-profit-corporation closed-source process that is the problem. It's not the code that is the problem, it's the process.

The reality, as Warren so eloquently pointed out, is that computers do not parse manager-speak. Computers process binary instructions, and that's it.

I'll expound on the idea: the process itself is the culprit. There is no shortage of smart, get-shit-done types out there in computerland. Just look a the development of stuff outside corporate walls like nginx, django, turbogears, wsgi, RoR, D, the upcoming JavaScript, the upcoming Python 3000, Linux itself... I point you, gentle readers, to

http://www.informationweek.com/news/showArticle.jhtml?articleID=204202971&pgno=2&queryText=

Where Linus Torvalds says:
>In contrast, look at where Linux is used. Everything from cellphones and other small embedded computers that people wouldn't even think of as computers, to the bulk of the biggest machines on the supercomputer Top-500 list. That is flexibility. And it stems directly from the fact that anybody who is interested can participate in the development, and no single entity ends up being in control of where it all goes.

>And what does that then lead to? Linux ends up being very good at a lot of different things, and rather well-rounded in general. It's also very adept at taking up any new niche, because regardless of where you want to put it, not only has somebody else probably looked at something related before but you don't have to go through license hassles to get permission to do a pilot project.


You see, the kind of innovation that Mr Anderson claims CIOs fret about, from the fourth paragraph in the Oracle article:
>
IT execs struggle daily, he said, with limited budgets and ever shifting requirements, evolving compliance and governance issues, and a growing autonomy within individual business units - fostered by blogs, wikis, and other collaborative Web 2.0 software - that is causing them to lose control.


That kind of innovation, the wiki engine written in PHP, ruby, or python, the blog written in ruby, php again, or python, the collaborative web2.0 site written in php, ruby, python, all with mySQL backends or some other unserious database with some unserious programming language with unserious documentation (LaTeX, you call that documentation? I want WORD documents!--Screams the clueless VP). Yes, that kind of in-your-face we don't care if our page is down or looks ugly (hello Myspace), and we don't care if our site is down daily (hi Twitter, lov'ya), and we don't care if our site shows "George Washington is gay!" mid-afternoon (checking my Wikipedia watchlist as I type)... Yes, that kind of innovation, this kind of developed-by-developers programs and systems are challenging established business IT because they are easy to install, intuitive to use, and add real value to the community and to individual contributors (AKA Lusers).

Anderson says: "We need a new platform that's driven by business processes, not code. The expression language needs to become business processes, not code." And I agree! The business processes to IT processes now suck, and cause all kinds of problems. The code is coded, optimized, unit tested, integration tested, system tested, and deployed according to the 400 pages technical specification. Yet despite all that, it is not serving the customer. Instead, the customer turns to facebook or to mediawiki installed by a rogue IT operative in a repurposed desktop under a desk on the 8th floor and memorizes an IP address to access the Ubuntu-running-in-violation-of-all-that-is-Holy-non-redundant-barely-backed-up-wikipedia-clone. (Can you tell I speak from experience?)

Why? Because the customer was not able to express what they wanted, especially after the royal munging that is commonly referred to as the business specifications document.

In opensourcey land, developers have public email addresses. They listen to all comers on public mailing lists--so easy to use that anybody with a hotmail account can hop right in (and they do)--and have to defend their position against know-it-all pimple-faced teens who read "ASP.NET in 24 hours" and suddenly just know how to build a massively scalable website.

Although to be entirely honest, the pimple-faced teen who just read "ASP.NET in 24 hours" has a much better grasp of internet technology than your typical corporate IT manager.

So these developers, who let all the world know their personal problems, fears, and financial problems, are living a declarative lifestyle and welcome, even encourage frank and gutsy conversations from the customers. They want people to tell them what sucks on their websites/applications. And the hotmail-wielding pimply-faced noobs indulge mercilessly.

Yet, in spite of all that, good software, agile software, flexible software, self-healing, self-updating, self-deploying (is that a bug or a feature Mr Worm?) software get developed and adopted by millions despite the fact that there was no project manager, there was no VP of Application development, there was no 7 environments (pre-dev, dev, testing,QA, UAT, PROD and I get confused), there was no 400 pages of documents outlining every single in-itself-innocuous feature that turned into a monstruous collective of unusable madness, and there certainly was not a Steering Committee with a Excel priority list the size of a small database with green and red arrows in the Priority column.

No. There was a small team (go read about youtube's here: http://highscalability.com/youtube-architecture) and there was mad skills and there was dedication and camaraderie and there was a vision.

I work in IT in a Fortune 500 and there is none of that. Why? Because there is the soul-crushing process that gets in the way (totally--I don't even answer the phone from customers--what's the point?) of the people doing the work talking to the people using the work.

Indeed, the industry knows this. There is a fix on the horizon, and it's called ITIL. It's a layer or process that is basically CYA for IT management, along with a long itemized invoice for the business, painstakingly detailing every little improvement so that "business" will realize all the hard work IT is doing and will loosen the purse stings a little more next budget season.
There is still the remnant of such a tool: SOA. It's the SOAP+ESB+WS* demon that only works if you're willing to sink $500M into it, and that by virtue of the overlooked fact that the smart people that get-things-done were lost in the shuffle and got it working at the 11th hour, unbenownst to managers who gleefully cheered yet another successful implementation without the faintest idea about the "code" that the computer cores actually process.

The fix? Google's close. See http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

The reality is close to what people aren't willing to talk about, meaning the dead horse on the table: IT as we know it is obsolete. Its model of hierarchy with top-down command and solid, repeatable processes is holding back innovation in the enterprise. It's not holding back innovation outside the enterprise, and that's why there's so much innovation outside the enterprise. Inside, the creative, quirky, eccentric, xbox-playing geeks quickly lose all hope and turn drab, dronish and dour under the high walls and low uv-lit ceilings of managed processes and compartmentalization. All the cool (still energetic) developers at my company, yours truly included, pour said energy into non-work side projects. Why? No red-tape, no endless meetings, no bullshit.

IT management is what is holding back technology from being used effectively in the workplace.

Now, to address the one issue that people are always throwing up as an excuse not to change: the need to follow regulations, such as HIPAA, SOX, etc. Tell me. What's the point of doing any of this if your regulation-compliant top heavy IT management process takes the rest of the company straight into being delisted from the NYSE? It is the job of the top management to figure a way to follow regulation as well as embracing the new style of development. This is what the competition will be doing, and this is why you went to fancy business schools, Dear Executives.

So, to sum up: Oracle is right that things need changing, and Oracle is wrong in the way to get there. At the end of the day, you need talented developers who understand the business and the needs of individual business users to write "code" for the computers.

Sunday, November 11, 2007

Browsershots

Great online app that takes screenshots of your website witha bunch of different browsers on different platforms.

CNN and Iraqi red crescent on IRaq's abandoned children.

It's a disgrace. Man can do better.