DJ1.0 is a contributing editor of TechDarkSide.com. We don’t know much about DJ1.0, since he participates in the dark side anonymously. We suspect DJ1.0 is a “he” since he refers to a wife in an early post, but then again, maybe they’re from Massachusetts… Either way, you can reach DJ1.0 at email@example.com.
In my previous post, I described the natural tendencies for people to dismiss as “useless” certain skills and knowledge. By extension, the people who use or have those skills are treated as “useless”. This in turns leads to conflict and sub-optimal teams that are not utilizing the hidden and unique skills of each member.
After reading this, someone said to me, “Well that post was useless.” You may agree. Of course, missing the irony of that statement is precisely the point of this post.
Usefulness is an assessment of a certain kind of value, namely utility. Utility depends on context, audience, and any number of other situational factors. All things are not equally useful, nor is the same thing useful the same way all the time. It is not always obvious but we need to avoid this kind of thinking. It is better to have a culture where value evolves from context instead of being dictated a prior. (Speaking Latin is definitely NOT useless. )
Here are some examples of skills, knowledge and attributes that are often overlooked, under-utilized and often punished.
Far from being useless, legacy knowledge about older systems, cultures, events, processes are more important now than ever before. These things grew up without the kind of documentation and traceability we have today. Sometimes all knowledge about these things only exists in people memories. Sometimes it is accidental; sometimes it is planned. However, that knowledge is extremely valuable, especially when it comes time to retire such a system.
This knowledge extends beyond understanding the technology of some crazy legacy system. Knowing the history of a system, or the back story on the culture or group that created it is valuable. Knowing the processes that exist and why some work-around became accepted is extremely important. If you don’t know where you have been, it is hard to know where you are going. People in IT ignore that at their peril.
This is about the natural connection between things. Mainframe programmers must get tired on enduring the remarks of their mid-range counterparts. They are constantly hearing about how the mainframe is dead. It is not dead; it is not dying. Not even close. Leaving that aside, how many people would think to involve their mainframe gurus in their SOA efforts. (Crickets chirping. Long awkward pause.) Exactly my point.
Connaturally is about the natural connection between two things. It is different than context which is discussed in my next post. The mainframe is – at its core – a shared computing resource. Mainframe departments are far from the dinosaurs others think they are. Mainframe groups have decades of experience with things like dynamic provisioning, large scale development, security and metering which most SOA groups are just now struggling with.
If you want a group with experience in real-world large-scale shared data environments, you go to the mainframe folks. Here is an entire group whose core structure, knowledge base and culture is built around managing, developing, testing, servicing and protecting a shared resource used by an entire company. Would not some of that experience naturally connect with SOA? Of course it would! It is a natural fit as long as someone doesn’t dismiss batch COBOL as useless.
In my final post on this, I will visit a few more items that we in IT tend to ignore.