Technological Decision Making

-
I'm amazed at how flawless some people think they are. Judging by the responses I often get to questions, I happen to work at an organization with a handful of people who NEVER make mistakes and know the answer to EVERYTHING. Oddly enough, though, these people seem to always have to work with a bunch of morons who never understand the genius in their presence.
It seems like my job has become that of gradually bringing a lot of these folks down off their high and enlightening people to problems with their reasoning. There seems to be an abundance of overconfidence in IT that "I know what I'm talking about" without and abundance of careful thought about all the options available to us or the inevitable consequences (everything has a down side). The troubling thing is, while there are obviously solutions to make this determination (documentation...), there are really no economical ways to determine if someone has done the careful thought or not in the time scales our projects typically run.
My job now is finding people who have actually thought about the problem (and making this determination is HARD) and exposing their ideas and insights to people who are making arbitrary decisions based on little, flawed, or no information. Put another way, it's all about educating everyone in my sphere of influence so that the entire team builds off of each others knowledge and experience.

Comments

Unknown said…
Hmmm IT folk who never make mistakes and know everything? They must be some form of new manager / tribble because they seem to be replicating at my place of employment as well.

Some people don't want to help themselves or receive knowledge from others, they're a lost cause. Logic has no home in their universe as they ride the coat tails of others and blow smoke like a wind machine. They speak in generalities and dismiss factual data as conjecture.

However, don't under estimate the value, awesomeness and scarcity of "the guy." This cocky fellow seems to have mastered the art of Google queries, reading documentation/manuals and trying new things. Odds are you are this guy...it's okay to announce your technical prowess and dominance in your field. Impressionable minds are listening.

Stay vigilant.

mgreen
March 3, 2009 at 8:58 PM
Mike Mainguy said…
Ahh, the mark of a true IT geek, you used a "Star Trek" reference... Your kung fu must be great oh master!
March 20, 2009 at 6:14 PM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more