Is there really anything more fundamental to our privative understanding of this world than our ability to make associations? Associations are our metaphors for data, they are our symbols for relationships. They make sense out of the senseless by forgetting the noise and, instead, concentrating on the lone harmonic tone.
For all those endlessly inter-connected, infinitely complex systems within the fuzzy world of Eisenstein chaos that exist beneath this simple Newtonian world we experience, it is the one perfect image of an apple, falling from a tree, that represents in our minds that compound curve of time-space we call gravity.
A good, solid association makes so many things clearer.
The team is working on associating all collectible data generated by our online readers. My job is finding the right symbol, the right metaphor that captures the essence of a number. For numbers are very elusive in their true meanings. They are very similar to words in that regard. Unskilled writers (me) use words bluntly to stutter out our ideas. A poet, however, can find the right words to extract the exact expression.
The numbers are slowly revealing themselves to me. I know I have found the essence of a number when a clear association snaps into place and won't let go. Once number and association fuse, clarity overcomes chaos and things become simple, honest. Powerful associations bridge any amount of data complexity and present the viewer with single, understandable, attractive connection. A single apple, falling from a tree. It is from these images that imperfect, beautiful human understanding grows outward and upward.
Friday, June 29, 2007
Thursday, June 21, 2007
Software Protocols
Now, Im no software engineer. So I wanted to relate Software Design to something I do know. Here's what I found:
Curious about where it all began, I started looking in the most erudite collections of lore on the subject of software's history. My research came back surprisingly thin, I'm afraid. It seems searching any combination of words on Google right now returns only blog postings about the iPhone, why not to by the iPone, and countdown clocks to the exact moment you can say you didn't buy that iPhone.
When that didn't work, I decided to ask a fellow highschool alum for a quick history lesson. Apparently it started in the 80's when some kid wrote something called BASIC for a toaster with lights and ended just recently with something called .NET for Vista. Seems after that latest product shipped, all Java and C++ programmers simultaneously quit their pointless jobs.
In between, an entire ecosystem of new and exciting programming languages evolved. C, C++, Java, Perl, Python, PHP, SmallTalk, Ruby, JavaScript, VB [breath], awksedfortrancobolpascallispprolog [gasp]. Innumerable methods to use these languages sprang up like weeds fertilized with a rich supply of Marketing Department byproducts. Consultants tended the fields well, producing a bountiful crop of Enterprise Solutions for the average consumer to choke on. Each is specially blended with proprietary features and locked-in functions to give you that warm "welcome to the middle of the crowd" feeling.
Now, the Networking World isn't nearly as fragmented. You have Cisco. Then you have other guys who aren't. I've worked with them all, and it really doesn't matter what product you buy. Given a little time and support, most anything will talk to anything else. Not that they want to, mind. Its the protocols that force the issue and make networking companies try to play nice. Networking protocols are no different than other, more commonly accepted rules. For example, protocol in the US says we drive on the right, the steering wheel is on the left, brake is next to the gas, cub holder is too small for a Slurpy. No car company would break the common protocol, even if they could. That means I can drive my Taur-ass 364 days of the year and my wife's sick CR7 one day of the year and not wreck.
Software Engineering is coming around with Distributed Computing and Component Driven Design. The idea being we should maybe think more about how our shiny new app will play with those forty other shiny new apps. Every application should look to how it will share its information or service with others, typically by using messages sent within a standard (or protocol) for communicating information. Unix had it right 30 years ago in its philosophy that you don't bolt on functions to a tool, you build a new special tool and let it communicate its results with its peers.
So if software was market driven to follow protocols, we would see more applications that had to follow basic SOA methods before they left the drafting board. That would mean buying application (or building them) that just enough to fill your need. No waste, no want. It also lets you use the right language for the job without sweating the previous environment. Or even, dare I say, upgrade your toolbox by working with fresher languages and just plugging it into your systems. Certainly your exposure to risk is lower when you only have a small application tying into the Distributed Computing net.
Oh, man. My programming team is going to hate me.
Curious about where it all began, I started looking in the most erudite collections of lore on the subject of software's history. My research came back surprisingly thin, I'm afraid. It seems searching any combination of words on Google right now returns only blog postings about the iPhone, why not to by the iPone, and countdown clocks to the exact moment you can say you didn't buy that iPhone.
When that didn't work, I decided to ask a fellow highschool alum for a quick history lesson. Apparently it started in the 80's when some kid wrote something called BASIC for a toaster with lights and ended just recently with something called .NET for Vista. Seems after that latest product shipped, all Java and C++ programmers simultaneously quit their pointless jobs.
In between, an entire ecosystem of new and exciting programming languages evolved. C, C++, Java, Perl, Python, PHP, SmallTalk, Ruby, JavaScript, VB [breath], awksedfortrancobolpascallispprolog [gasp]. Innumerable methods to use these languages sprang up like weeds fertilized with a rich supply of Marketing Department byproducts. Consultants tended the fields well, producing a bountiful crop of Enterprise Solutions for the average consumer to choke on. Each is specially blended with proprietary features and locked-in functions to give you that warm "welcome to the middle of the crowd" feeling.
Now, the Networking World isn't nearly as fragmented. You have Cisco. Then you have other guys who aren't. I've worked with them all, and it really doesn't matter what product you buy. Given a little time and support, most anything will talk to anything else. Not that they want to, mind. Its the protocols that force the issue and make networking companies try to play nice. Networking protocols are no different than other, more commonly accepted rules. For example, protocol in the US says we drive on the right, the steering wheel is on the left, brake is next to the gas, cub holder is too small for a Slurpy. No car company would break the common protocol, even if they could. That means I can drive my Taur-ass 364 days of the year and my wife's sick CR7 one day of the year and not wreck.
Software Engineering is coming around with Distributed Computing and Component Driven Design. The idea being we should maybe think more about how our shiny new app will play with those forty other shiny new apps. Every application should look to how it will share its information or service with others, typically by using messages sent within a standard (or protocol) for communicating information. Unix had it right 30 years ago in its philosophy that you don't bolt on functions to a tool, you build a new special tool and let it communicate its results with its peers.
So if software was market driven to follow protocols, we would see more applications that had to follow basic SOA methods before they left the drafting board. That would mean buying application (or building them) that just enough to fill your need. No waste, no want. It also lets you use the right language for the job without sweating the previous environment. Or even, dare I say, upgrade your toolbox by working with fresher languages and just plugging it into your systems. Certainly your exposure to risk is lower when you only have a small application tying into the Distributed Computing net.
Oh, man. My programming team is going to hate me.
Tuesday, June 19, 2007
The true mother of invention
Im not sure how it happened. One day, while minding my own business running the IS department for a large B2B publishing company, I decided to try something a bit wacky and took one step forward. Maybe I took no steps forward and the rest of the group silently snuk back a foot. Either way, I (was?) volunteered. To do what? Well, just to pretend to be something I'm not for as long as it takes to become that something. To fake it until I make it. No problem, Im a smart guy. I can do this. Ok, actually one problem. How do you fake being something most similarly categorized people earn through 4 years of school and a decade of hand's on experience? How do you pretend to be a Software Development Manager when you can't write an application?
Now I'm no milk-fed mama's boy. I'm a network engineer, and a damn good one. I cut my teeth in one of the toughest financial institutions in the country and when they say zero down time, well lets just say it wasn't a jumping off point for negotiations. I worked my dues and I know why the watering down of the term Enterprise Class chaps the collective asses of the true IT professionals who keep this country running. I've slapped together some impressive Perl that ran a million dollar department for 9 months until their Java team could replace it with something, well, more OO that did the same damn thing. I've written that Rails app that scratched the CEO's itch and made the company ROI near instantly. I've hacked, slashed, and patched enough to become that annoying little gnat in App Dev's ear. But I am not a programmer.
As IS Manager I never babysat my people, I worked with them. I took the calls and worked the late nights and solved the mysteries and took the lumps right along with them. Taking this job meant I would have to hold my own in their world. My Cisco collection would become O'Reilly. Eclipse would replate Telnet and SSH on my desktop. Id have to start wearing polo shirts in brain-numbing patterns.
It is crazy for a hardware guy to even try to break into the enterprise software world, especially at the top. Or so they say. Maybe thats the reason I took the job. Proving people wrong is something of a natural talent in my family. We wear our victories over other's narrow mindedness like well earned war wounds. Only this time, it wasn't someone else that needed convincing, it was me. I was up against my own fears; afraid to leave the comfort zone of that cushy, stagnant, all but conquered position as IS Manager. But equally afraid that I would rust over if I didn't branch out into something, anything new.
So stubbornly I pitched my case to my boss. How would he like to have the best Software Development Manager in the industry in two years working for him today? Well I know it was corny at the time, but would you believe it worked? Ok, I wouldn't either. But I knew something the reader does not. Our company was and is growing very fast. It was in a unique position to entertain unconventional initiatives from promising prospects.
This blog will be a personal journal of what I learn on the way to becoming the best Software Development Manager in the industry in two years. I almost feel sorry for whomever holds the title belt now. Fair warning, Im gunning for ya.
Now I'm no milk-fed mama's boy. I'm a network engineer, and a damn good one. I cut my teeth in one of the toughest financial institutions in the country and when they say zero down time, well lets just say it wasn't a jumping off point for negotiations. I worked my dues and I know why the watering down of the term Enterprise Class chaps the collective asses of the true IT professionals who keep this country running. I've slapped together some impressive Perl that ran a million dollar department for 9 months until their Java team could replace it with something, well, more OO that did the same damn thing. I've written that Rails app that scratched the CEO's itch and made the company ROI near instantly. I've hacked, slashed, and patched enough to become that annoying little gnat in App Dev's ear. But I am not a programmer.
As IS Manager I never babysat my people, I worked with them. I took the calls and worked the late nights and solved the mysteries and took the lumps right along with them. Taking this job meant I would have to hold my own in their world. My Cisco collection would become O'Reilly. Eclipse would replate Telnet and SSH on my desktop. Id have to start wearing polo shirts in brain-numbing patterns.
It is crazy for a hardware guy to even try to break into the enterprise software world, especially at the top. Or so they say. Maybe thats the reason I took the job. Proving people wrong is something of a natural talent in my family. We wear our victories over other's narrow mindedness like well earned war wounds. Only this time, it wasn't someone else that needed convincing, it was me. I was up against my own fears; afraid to leave the comfort zone of that cushy, stagnant, all but conquered position as IS Manager. But equally afraid that I would rust over if I didn't branch out into something, anything new.
So stubbornly I pitched my case to my boss. How would he like to have the best Software Development Manager in the industry in two years working for him today? Well I know it was corny at the time, but would you believe it worked? Ok, I wouldn't either. But I knew something the reader does not. Our company was and is growing very fast. It was in a unique position to entertain unconventional initiatives from promising prospects.
This blog will be a personal journal of what I learn on the way to becoming the best Software Development Manager in the industry in two years. I almost feel sorry for whomever holds the title belt now. Fair warning, Im gunning for ya.
Subscribe to:
Posts (Atom)
