Monday, October 23, 2006
MS had already jumped into dynamic languages with the acquisition of IronPython. Now it only a matter of time until "Ruby#" or whatever MS will call it (since there is already a Ruby.NET project, which is heading in yet another direction). *nix purists and MS haters may be cringing, but I think it quite legitimizes the Ruby meme to naysayers who may have thought Ruby was just a fad.
Working in the big corporate space, one of the primary objections that I have encountered to implementing systems written in the Ruby language, is needing to run on Windows and use existing complex .NET services that are already deployed in the enterprise. A Ruby coming from Microsoft, on top of a Ruby coming from Sun (JRuby), just sends a clear message to corporate types that "This Ruby thing is real". Heh. Heh heh, even.
Many of us have been trying to get Ruby taken seriously for a while, and this is exactly the kind of ammo that dead programmers need to not just sneak Ruby in, but storm the castle walls! Ruby will rule!
Software testers are considered "lower on the food chain" then software developers or analysts. That means testers are compensated less than their developer or analyst counterparts. Even on many important projects, across both companies and industries, this is still the case. This amazes me, given how much of the world runs on software. If the software that runs your airplane's landing gear, or your electronic voting system, or whatever other ultra-critical system has not been sufficiently tested, lives can be at stake. Despite the fantastic work being done in the area of software quality, and the proliferation of practices that can dramatically reduce the cost of creating and maintaining a system, we still all too often see quality getting shortchanged on required resources.
So testing is good, and we need more of it, surely. But we need to go further, much further. Giving proper attention to test-driven development is great. But even all this is not enough. What we need to do is to apply a test-driven mentality to all aspects of business. Marketers have found that testing and measuring their marketing yields a far greater ROI then marketing based on opinion or theory. Salespeople have been measured by quotas, and the most successful sales organization performing testing for some time.
In particular, we need to move toward management philosophies that apply testing to business decisions, in particular those about processes. All too often, decisions have consequences often than those intended, perhaps failing in one of more objectives. A new process designed to streamline a company, can actually result in adding more burden with less efficiency.
Without the ability to test, management will eventually lose control over itself. With no feedback, failures may be looked at as successes, and vice versa. Management cannot be arbitrary; by carefully adopting a test-driven culture across all disciplines within an organization we can improve both the quality of our work, as well as the quality of the experience we have while doing that work.
Sunday, October 22, 2006
I just saw a really neat new gadget called "The Device Patented Process Indicating Apparatus " for the first time. Check it out at http://www.processindicator.com/
It is a USB device that can be connected to take whatever data feed you desire, and use the "inscrutable dials", Ethereal Glowing Tube (EGT), and incandescent lamp on "The Device" to indicate whatever status you want. "The build is broken", "sales are up", or "there is a soccer game today" are only some of the neat automation possibilities that come to my mind without much effort.
The only process indicating apparatus you'll ever need, indeed! Too bad they are not yet for sale...I want one of these! It is the coolest thing I have seen since the "Ambient Orb".
Thursday, October 12, 2006
Knowing the business is great. In fact, knowing the business is essential. I hope that business experts abound within your organization. But "architecting" is not what these people are doing.
Here is a list of some of the knowledge, skills, or qualities that I think are required for anyone who wants to be called "architect". In no particular order:
- Speaks in terms of design patterns
- Uses open source/commercial off the shelf(COTS) software
- Can determine the least cost solution for a particular business need
- Desire for a career path in technology which is NOT management
- Knowledge of both current and next-generation technologies, so that development efforts can be synched up with other developers in the industry
- Knows how to avoid or get out of anti-patterns
- Embraces simplicity as a fundamental design principle
- Can embrace the good ideas of others
- Unafraid of change
Do you know who the architects are in your organization? Are these the qualities that they are known for?
Wednesday, October 11, 2006
This post on the "Creating Passionate Users" blog really sums up what makes a Dead Programmer, well....dead!
A colleague of mine once quipped, "Why is it that at some point in most people's career, they suddenly decide that they now know everything and don't have anything else to learn?". That is around the point that they are past the point of no return converging on the "micro-manage every detail" side of the "Zombie Function" graph.
So what happens to these poor middle managers? Is it the tribal "showing the size of one's beak"? Or is it a kind of post traumatic stress disorder, brought on by being way into the "anxiety zone" (I will post about the state of flow soon).
Odd that the very factors like creativity and free-thinking that can most stimulate success, are the ones most likely to be blocked by management at many companies.
So what can a poor, Dead Programmer do about it? Speaking truth to power is both difficult and dangerous. If you really think you are ready to take on a monoculture within your organization, you had better prepare. Once you finally get your chance to pitch them, you will only get one chance. Writing down your ideas well in advance of this can refine them down to the size of information packet that management will be able to digest.
Focusing on new solutions instead of dwelling on the mistakes of the past is also a good idea. This is particularly true when speaking to the individuals who got the company into whatever mess it is in, in the first place. Be very diplomatic, but still take a firm stand ("tough love"?), and keep it far, far away from anything that can be taken personally.
Lastly, keep in mind that only benefits that will really impact the business are important enough to risk the firestorm that sometimes arises when confronting a zombie organization. When I say impact the business, I mean either bring in major new sources of revenue, or dramatically reduce the cost per running tested feature.
Small incremental improvements to the organization are best implemented from the bottom up in a "stealth mode" project. More about that next time...
In a world where taller people tend to more successful, I guess it makes sense. But logic has nothing to do with it! And things that lack logic offend the sensibilities of any self-respecting Dead Programmer...
This site is dedicated to the Dead Programmers who dwell inside the corporate world. Not really so much dead, but slumbering.
Wake up, wake up... and carpe codex!