Use the window below to chat with me (if I'm online ...)
Use the edit nick field above to let me see your name.
cazh1: on Business, Information, and Technology
Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Saturday, September 06, 2008
Linkfest: Data Visualization
I'm a long-time fan of effective visualizations, and I've often written about the effective use of visual information when making presentations or communicating complex information. I've subscribed to my share of blogs and feeds on the topic, and have amassed quite a backlog of interesting links ... presented here for your hyperlinking enjoyment ...
Best Blogs
information aesthetics - If you appreciate the good stuff when you see it, and like to see the best (to stimulate your own thinking), this is a great resource
kottke.org - a broad range of topics, but they have posted a lot on information visualizations - this tag link will take to to the latest and greatest
Facebook Social Network Graph (via information aesthetics) - I've finally put a bit of work into Facebook - I'm beginning to understand it to be a necessary complement to LinkedIn - so this application looks interesting. Of course, I need to get more than three "friends" ...
catalog tree (via information aesthetics) - This site is loaded with a wide variety of infographics - definitely will get the creative juices going
posted by James P. MacLennan at 11:25 PM
| Permalink
|
|
Friday, August 22, 2008
Facilitating Innovation: Establishing an Environment of Possibilities
Facilitating Innovation: Establishing an Environment of Possibilities
I'm exchanging email with someone interested in establishing a skunk works, and they are asking some very interesting questions about the nature of innovation and the ingredients for an "environment of possibilities" ...
... things are ... [as they are] because someone already tried unsuccessful alternatives ... [This] begs the question: when it is required, how can rapid innovation be achieved?
Rapid innovation comes when the environment allows it and the skill sets enable it.
An "environment of possibility" just means that folks are given some time to experiment with new technology, and access to the resources required to play around a bit.
Caveat: The challenge, of course, is that many folks expect the employer to allocate x% of their 40 hour work week, and provide training classes and server space to mess around with. Invest a little personal time and capital - in IT, it doesn't take much to build a solid development / test environment and start teaching yourself!
I believe that the "innovation skills" are in everybody. But just like any other activity, success is 10% inspiration and 90% perspiration - individuals / teams / organizations need to build their innovation muscles by doing.
Caveat: A critical requirement for this piece is has to be ok to fail. The corporate culture must expect a failure rate for new ideas - remember, if it was easy, we'd probably already have thought of it!
... I value both history and future opportunity and am seeking a balance. Is this the same in your experience?
Well, Santayana was right - "those who do not remember the past are doomed to repeat it". But history should tell you specifically what tactics to avoid, but not necessarily what strategies will fail. Opportunity will be a mix of many things, and what was true at one time may no longer be true now. Look at imports from China - recent increases in transportation costs are making that strategy a loser for lower valued goods.
(and now, the "How-To Questions About Skunk Works")
Process: How does ... leadership successfully position a think tank or innovation team so that it is (a) buffered from mundane corporate operations and politics while (b) it remains sufficiently connected to executive leadership and operating divisions for its ideas to be acted upon? (I'm assuming that the skunk works is outside the normal corporate business structure.)
Ah, this is an incredibly important question. Skills and environment aside, I've seen successful innovation happen only when the team was sufficiently empowered to get ideas implemented. Sometimes this comes from executive sponsorship from just the right person - but not as often as folks think! The cynical or weak of heart prefer to wait until they are granted permission to work on a project or idea.
The "drivers" that get stuff done do so because they have all the rah rah stuff (vision, drive, energy, whatever), but they also typically have knowledge of how things work in a company. Sometimes this means a long-time employee, who has relationships with the folks that control the key people, resources, and decisions. Sometimes this means the uber-techie who already knows how the various pieces of process and technology work, so they know how to call out the resistors when obstacles are thrown in the way (no budget! no approvals! too difficult! systems can't do that! it's against policy! yada ...). And you don't have to be a long-term member of the organization to be successful; experiences from multiple industries, organization, technologies, etc. can all be applied by someone with imagination and drive.
So, leadership needs to stack the deck for their innovation team by ...
Carving out time in their schedules; don't just add this to everything else on their plate - take something off!
Provide visible executive sponsorship. You need to be able to pull that card out every once in a while (You need to make this change because the CEO said so ...) - not often, but now and again ...
Staff the team with a mix of long-term and newer employees
Identify a team leader that has the right mix of hands-on technical (this cannot be a administrative role only - they have to be able to do something!), business, and relationship-building skills. They must be able to spot the opportunity through the hype, understand how it translates to business value, and then communicate that effectively and concisely to those who need to support it
Hold their feet to the fire - the team should have goals and objectives, it's not a license to play!
Let them fail! The most successful baseball players fail 70% of the time!
Also, the skunk works must remain connected to operations - they'll have to implement the "big ideas" eventually, and it's always good to remain grounded in reality. Make participation on the team a part-time thing for most; consider rotating different people in from various areas of the company, so everyone has a chance and all remain connected to the base business.
What lessons have you learned from the skunk works experience that you can apply to the innovation process? What broad, meta-issues and narrower specific issues has your project illuminated and solved (or at least, what questions has it posed)?
Aside from the organizational and change issues mentioned previously, I have found that innovation efforts often target things that are perceived as issues, but they are actually symptoms of more fundamental behavioral or structural problems. Web 2.0 tools and techniques are often lauded as new ways to unlock the wisdom of the crowds, connect with the new work force, or counter the flight of knowledge leaving the company upon retirement. Unfortunately, some of these efforts struggle due to what I call the Law of Large Numbers, which basically says that what works on the Internet doesn't always work at a corporation.
Also, it always seems to boil down to "Change Management" - an overused buzzphrase that just says change is hard (especially from a vending machine). There are many ways to address this (education, repetition, participation), but management always needs to understand that corporate operating processes typically don't catch on like consumer products - here today, gone tomorrow (look how fast the Apple iPhone turned over a new version!)
posted by James P. MacLennan at 10:39 PM
| Permalink
|
|
Friday, July 11, 2008
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!
However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!
Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...
What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.
Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.
... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...
Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!
posted by James P. MacLennan at 1:58 PM
| Permalink
|
|
Sunday, July 06, 2008
Don't Accept Snap Answers Too Quickly
Don't Accept Snap Answers Too Quickly
A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I've done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:
Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified - DateLastUpdated, something like that?
His answer came back almost immediately ... No. Well, I guess this is possible, but we're working with a fairly up-to-date ERP, and I've worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly ... so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) ...
I mean no disrespect, I am fully aware of your experience and skill on this particular platform - but I need to be clear, because I think I'm asking for something that's fairly basic.
I just need you to be a tad more specific when you say 'the system doesn't do that'.
Is it more accurate to say 'I have never seen the system do that' or do you know for a fact that that the system cannot do that?
It's a subtle difference, but it's important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I'm humble enough to know there are many features and functions in any platform I've ever worked on that I don't fully understand - never had the need. Plus, I don't see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I'm asking for something that I've seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.
Truth be told - in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality - but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work ...
Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps - many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the "local expert" - but if the right questions saves a ton of effort, searching for a workaround - well, that's an excellent question to ask.
posted by James P. MacLennan at 9:53 PM
| Permalink
|
|
Monday, May 26, 2008
Politically Correct Euphemisms in IT - Translated!
Politically Correct Euphemisms in IT - Translated!
I recently attended a professional seminar, and noticed a propensity for politically correct euphemisms to describe life in corporate IT. This was a typical group of IT professionals, representing a variety of companies - small and large, public and private. As with most group meetings, we started with a trip around the table; quick introductions, plus some highlights of "what's hot" for IT these days. The careful language wouldn't fool the experienced; however, a casual listener might see the knowing smiles on the nodding heads and think that we were either participating in a great conspiracy or dazed from too much coffee.
As I aspire on these pages to improve the quality of communication between IT and business, I feel duty bound to provide this partial translation page - what they say versus what they mean.
The project has been a challenge ...
We bit off way more than we could chew, and will probably blow the budget by 50%
We are considering ...
We talked about this one over beers, but there's no chance in heck of going forward ...
... looking at opportunities for SaaS ...
We're under budget pressure, and are desperate to say something to keep Finance off our backs about data center costs.
The database is growing rapidly ...
We massively underestimated growth rates, and are scrambling for capital to buy more disk.
The developer is quite aggressive ...
... they don't have time for documentation, debug in production and have polluted their workstation with multiple versions of component libraries that will cost millions to roll out
We did a pilot in CRM, and now we are comparing to salesforce.com.
The sales team played with it, realize they have to actually type data into the system, and now they're trying to delay as long as possible.
- alternative -
They asked for a shared contact database, we came with a $3M package implementation, and now we're scrambling to save face ...
... that's gonna stress us a bit ...
Another six months of nights and weekends? Good thing my resume is up-to-date ...
We have managed to create 18 instances of the ERP
The business can't make organizational decisions
- alternative -
Our development teams can't agree on a common QC cycle
- alternative -
We never had a long-term plan, this grew by evolution, and now we need a revolution
We've implemented (insert module name here) - which is ... interesting
This thing has more bugs than a VW convention in a swamp; we're in a first name basis with the core development team, and half the code has our IP in it.
... using the latest and greatest, and some we're still waiting on ...
The rep sold us vaporware, and we've already maxed his voicemail box demanding a delivery schedule (or a refund)
... after a lot of pain, discussion and analysis ...
we are on our fifth attempt at implementing, but the business sponsor can't cancel because he's overcommitted on the ROI
It's a legacy system, home grown, and its old.
We've gone through five lead developers, the original author is playing shuffleboard in Florida, and if the disk crashes we're hosed because we don't have the source.
This is going to drive quite a lot of work.
I'm stunned at how poorly thought out the project plan is ...
[ long list of acronyms and letters]
We are rabid technologists ... by the way, how come executive management doesn't invite me to meetings?
We're revisiting [something] (strategy, software package, implementation approach) after the acquisition ...
Awesome! We can cancel this screwed up project and restart it after the new owner settles in!
- alternative -
The new team runs a pretty tight ship ... good thing my resume is up-to-date ...
We're going through a process of stabilization before rollouts continue.
We hit too many walls and the business is fed up, so the project goes no further.
- alternative -
Another high priority project came along, and we got pushed down the to-do list.
The biggest challenge is the cultural shift.
Technical implementation is equivalent to C:INSTALL, but we'll be in training classes for months.
We experienced a little bit of a hiccup.
When the install dialog said "Are you sure?", I experienced a giddy sense of optimism that was quickly countered by a suitably horrible sound from within the drive ...
It's a learning opportunity ...
It's a chance to hone our skills at backpedaling, debugging on the fly, and byte-level disk sector editing.
We met our service level objective
Good thing we sandbagged the the target run rate.
... and this is what's going on ROW (Rest of World) ...
We don't like international travel, so our strategy stops at the border ...
... (refers to ) my soon-to-be partner (acquisition/joint venture) ...
... my soon-to-be subordinate, unless kick him out of his chair ...
- alternative -
Good thing my resume is up-to-date ...
Regional translations may vary; I invite your input on additions and variations ...
posted by James P. MacLennan at 12:33 PM
| Permalink
|
|
Friday, May 09, 2008
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook)
The volume of Twitter posts popping up in my feed reader is ticking upward, a phenomenon I find interesting because of something I noted recently on LinkedIn. A few weeks ago, a new feature appeared, enabling me to report what I'm working on - Twitter for the office crowd. Always willing to try some flair, I jumped on the bandwagon, and set up a recurring ToDo for updating my LI-net on the day's focus.
meta-tweet
That lasted less than two weeks - some clear (and discouraging) trends had emerged:
Few people in my network were using this feature, and actively noting what we were doing - and it was primarily folks that I know are active bloggers, engaged in the practice of Web 2.0 (and they, too, have trailed off in their LI-tweets)
For the "regular" folks in my network, it was the one activity (daily or twice daily updates) that generated the most inbound comments. I got multiple e-mails, noting that I must be manufacturing additional hours each day.
Without fail, whenever you mention SAP, data warehousing, or any other specific technology, every product sales rep or consulting firm in your network will call that day and offer a$$istance.
I remain a fan of LinkedIn and social networks in general, but my personal jury is still out with Twitter. I think I want it to succeed, but I'm not sure exactly what it can succeed at. The ideas and innovationsarestillcomingin - one of them is sure to make sense to the wider audience, right? In the mean time, I just don't see it catching on in the mainstream enterprise business environment.
I wonder if the gap is generational, or just a different target audience? Much like the difference between Facebook and LinkedIn - is it GenX vs the Millennials, or is it social network versus professional network? Earlier this week, Bernard Lunn weighed in with his compare and contrast post, and observing that both platforms attempt to add Yet Another Messaging Medium to your current array. Dennis McDonald's reply post backs up the notion that there are different audiences in play here - he also has done a deeper dive in Facebook than I have, so if you want a more qualified and detailed comparison, check out Dennis' work.
Or maybe Hugh MacLeod (gapingvoid) has it pegged ...
insightful
Note that Mr. MacLeod is clearly a Twitter fan - maybe he gets this stuff it better than I ...
posted by James P. MacLennan at 9:55 PM
| Permalink
|
|
Thursday, May 01, 2008
RSS: Underappreciated Web 2.0 in the Enterprise
RSS: Underappreciated Web 2.0 in the Enterprise
We added RSS capabilities to our internal PMO systems this past month, and traffic & content is already building up to become a valuable resource. Some have [correctly] noted that this increased visibility puts a bit more pressure on project managers and team members, to keep updating project blogs with pertinent information. This "time shifting" of communication should develop into the most effective way to let the rest of IT know what is happening in all areas.
There are some very interesting threads and conversations going on ... for example:
One Supply Chain systems team informs us of process improvements in product development - nothing to do with IT, but interesting nonetheless
Another team is putting together ideas that will take some significant IT costs out - that's a very active thread
The SAP application team is debating with the Basis team on the merits of a Unicode upgrade - and onlookers from Supply Chain Planning and Data Warehousing are noting dependencies on Unicode in their platforms
These spontaneous, organic, and very impactful "conversations", between people still experimenting with a new technology, show me real potential for spontaneous innovation and idea sharing. More evidence of the value of [judicious] experimentation with new technology - no silver bullet, but just enough spark to start a few fires.
Interested in learning more about RSS? There's lots of good reading out on the Internet ...
Voyage is an imaginative RSS-feader which displays the latest news in the "gravity area". Interesting navigation - I don't think this is practical for internal use, but it sure looks good!
Newsmap translates news feeds and frequeny to a variable bar graph approach.
Universe DayLife is, well, spacey. Translates the universe of news and connections to stars ...
posted by James P. MacLennan at 7:48 PM
| Permalink
|
|
Tuesday, April 22, 2008
No Silver Bullet for Group Collaboration over Distance?
No Silver Bullet for Group Collaboration over Distance?
Lots of organizations have to deal with the challenge of implementing standard work and best practices over physical distances. With sales offices, distribution centers, and manufacturing locations scattered across the country, what's the best way to get people who know their stuff to collaborate on process improvement - and then take that knowledge back to their home office?
While wrestling with this challenge, one executive I know preemptively ruled out videoconferencing. It's a common suggestion, but the general feeling was that it's just not useful, has never proven itself in practice.
I happened to agree with the idea that videoconferencing wouldn't help in this situation. The team was talking about productivity improvements for an assembly process - workstation layout and hands-on participation was required to effectively work out the wasted movements. However, when defending the No Webcams position to some gadget freaks around the table, we came up with a/the fundamental flaw with remote video: it lacks spontaneity.
Historically, videoconferencing was set up in specific rooms that had to be reserved in advance. For higher quality connections, equipment is expensive, and the expense had to be pre-approved. Advances in digital cameras brought devices mounted on desktops, but this tied you to that specific location. Today's nifty notebooks have built-in cameras, but these can be tough to use with a group of people (crowding around).
Yes it's possible to use videoconferencing, but the physical limitations tend to quickly dim the excitement of all but the most diehard tech fans. In practice, local process improvement teams would just walk over to the workstation in question, skull out the best way to do something, and take a break for some coffee by the time we had the webcam hooked up ...
Lack of spontaneity is probably why the vast majority of PowerPoints are delivered with printed decks, and not overhead projectors. It's still more time efficient to quickly print off a few copies than it is to chase down a projector, lug it and your notebook computer into a conference room, get everything hooked together, and try to remember how to switch to the external monitor. (Hmmm, good thing they added all those cool slide transition effects ...)
Truth is, having paper copies isn't all that bad. Some folks like to take notes on their handouts and file them away for future reference. The medium of communication has its own utility, a sort of residual value that most people understand how to use. The same is true for fancy collaborative technology like videoconferencing. The magic is in the actual conversation, but that can get lost in the struggle to get the technology working before you can actually use it.
Does this mean that collaboration technology is doomed to failure? Of course not - knowledge capture and reuse, and differences in physical location and time zones, are still problems for organizations that rely on the "old way of doing things". You just need to pick your tools judiciously, and build up to the fancy stuff over time.
Wiki's will not work if people don't already have an interest / desire / skill / method for creating documentation. Wikis solve distribution and access problems, but they don't make people suddenly want to write.
Blogs will not work if people don't already have the need to communicate while competing for people's attention. Blogs solve time and distance chanllenges and facilitate simple Q&A, but they don't automagically endow authors with reader empathy.
Collaboration Spaces will not work if people don't already have the need to share documents and edit them within a group. Collaboration Spaces solve version control and tracking hassles, but they don't help groups create impactful documents where none existed before.
We needed to see productivity improvements in component assembly within 60 days, so flying a couple of key people around the country was a small price to pay for the quality of work that we got. We took a small step forward - getting process experts to a different location, to put faces to names, and empathize over common challenges, experience the satisfaction of defining a workable solution - and experience the joy of business travel. Maybe next time we could look into videoconferencing, because interpersonal relationships and understanding of the power of shared best practice has already been established.
posted by James P. MacLennan at 10:59 PM
| Permalink
|
|
Sunday, April 06, 2008
Why are those Old Programmers so slow in picking up on the Intarweb?
Why are those Old Programmers so slow in picking up on the Intarweb?
A significant difference between us old-line IT coders and the new graduates is the variety of our platforms and tools. I'm not talking about the large number of languages and tools learned over the course of a career - we all have a healthy collection of certifications and acronyms peppering the bottoms of our resumes. I'm talking about the amazing array of stuff required to get development done on a single project, "right now".
Over the past few weeks, I've been doing a little development at work. This is my idea of fun - in between the PowerPoints and project status meetings, I try to sneak in a little hack or two. Actually, I'm not doing the heavy lifting on this one; I'm working with one of the guys on my team, and we're putting together some ASP code to generate RSS feeds from the SQL database we use to track our projects. He's done most of the raw research and the base coding, I'm just prettying up the final package.
As a department, we're moving towards Microsoft as a strategic platform, but we're certainly not there yet - so this is definitely a skunkworks-type project. For this "fun stuff", we're using technologies that will plug nicely into our general strategic direction, but at this point there are no standard toolsets or integrated development environments in broad use.
So, to get the job done this afternoon, I've been cycling through the following ...
In window #1, editing the .ASP file with Crimson; source files are sitting on the development server
In window #2, testing code using IE ... no integrated debug environment for my ASP syntax, but I manage (just a little trickery - switches flip between RSS and HTML output)
This is just debugging the basic code - to validate the RSS XML, I View Source from IE (opening window #3) and cut and paste into the W3C validator (window #4)
For the SQL queries and database hacking, I've got window #5 for Enterprise Manager and #6 for Query Analyzer
After debugging, I push to the test server manually, using File Explorer in windows #7 and #8
Everything looks great, so I switch to window #9, which has another chunk of ASP that generates custom URLs for the RSS feed (we've added selectivity, aren't we crafty?)
For the final test, I have RSS Bandit open in window #10. I create multiple new feed URLs (#9) and add to the Bandit config, to see what I get
If I made a syntax error in the RSS (missed something between #4 and here), I have to flip back to window #1 to clean it up
Oops, almost forgot ... like any good coder, I've got TFMs open, but it's not just one manual- window #11 is my multi-tabbed Firefox, Googling all sorts of sites to get references for RSS, ASP, and SQL
Sounds crazy, I know. I could/should go out and get Visual Studio or something. But like I said, we're not fully in production in this Microsoft development environment. We're innovating, right?
I've done open source development on my own in the past, and it's much the same thing - multiple different platforms, tools, and languages. For example, when working on my own site, I'm fixing configuration files and writing code in HTML, CSS, PHP, and mySQL. To get things working, I'm dealing with the configuration files for Apache, Eclipse, PHP, and mySQL. Edits in Eclipse and Crimson, pushing around source with FTP, fighting firewalls and routers, developing in Windows while production is in Unix.
This madhouse of multiple tools, languages, and platforms probably sounds quite normal - if you've been working heavy with open source and/or Web 2.0 for a few years. But imagine presenting this to legacy IT folks, working in their version controlled, standardized environments. The typical "road to the future" brings five new technologies, three new IDEs, and one or two basic system architectures that are all very different from tried and true.
Does this mean you can't teach an old dog new tricks? Not at all - most are quite anxious to learn, and have done so continuously over the years. However, this is all starting to feel like the first time we switched from procedural languages (COBOL, RPG, Pascal, Fortran) to OO and event-driven stuff (Visual Basic, PowerBuilder, SQLWindows). We went from offense to defense, from being controlling and orchestrating to reacting and trapping. Not that it was bad or wrong - just different.
Does this mean the experienced coder is washed up, and has nothing to contribute? Ask the folks in Big Pharma, having dealt with the FDA and validated systems. Ask the folks working with Finance in public companies, having dealt with SarbOx. Healthcare and HIPAA. Retail and RFID. Not to mention having to debug a lot of other people's code, and knowing when to step through or just refactor.
Running to the future, juggling multiple multilingual windows, and demonstrated facility with the newest tools is all good, but it's just one of many attributes that determine who on your team is worth 50 others. Have a little patience ...
posted by James P. MacLennan at 12:13 AM
| Permalink
|
|
Friday, April 04, 2008
Branching Out: Writing for the FEI Blog
Branching Out: Writing for the FEI Blog
Yet another interesting way that the Internet has broadened my connections and collaborations ...
After connecting over LinkedIn and exchanging common interests via e-mail and blog post, the fine folks over at The Front End of Innovation blog asked me to do some posting there as well. They have a different posting style - shorter, a bit more volume than I can generate, and definitely focused on innovation (I know that I wander across many different areas of IT and business). However, I've got a series of post ideas I'm working on in the area of "innovation" - defintely a buzzword for 2008. I should easily be able to cross-post between the two.
Be sure to check out the other authors at FEI - interesting stuff, definitely worth adding to your blog roll!
