Thursday, March 29, 2007
Second Class IT Professionals who write Business Applications
A friend who recently bailed from his enterprisey position and migrated to a startup commented to me how he felt like a real IT professional now that he is dealing with boring business applications. I wonder if others in the blogosphere have this same perspective?
A general observation amongst many of my peers is that when they get home and start tickering with open source projects, they almost always gravitate towards infrastructure software whether it be operating systems, BPM engines, ESBs or ECM platforms. I have asked many of them why aren't they even noodling the creation of business applications in the open source space and receive lots of laughs.
Studying my own behavior, I think it is do to lack of interest in terms of wanting to capture domain-specific rules formed by others (aka the business community) where all the technical domains that open source has been wildly successful doesn't really require one to collaborate with non-technical folks like we do in an enterprise environment. Other reasons that I have ran across in my travels is that business applications while volumous in terms of lines of code and the need for structure tend to not be as intelectually challenging from an algorithmic perspective.
Open source could be wildly successful if it were to attack industry vertical challenges but could do so only when solutions to given problems are crystal clear. Business applications tend to have as a characteristic that there is no easy way to tell if your code is right without having to interact with lots of end users first.
Sometimes software developers have sufficient expertise and influence to suggest changes in business processes to make them more logical or efficient. Presenting ideas to a business domain expert requires skilful sales technique. Otherwise, you risk coming across as arrogant or pushy. In the business world being liked is often more important than being right, but techies often see the reverse, creating a culture clash of sorts.
Good solutions to tough change management problems are difficult to discover. It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales, and selling is generally an "intuitive" discipline. Thus, explicitness is often not expected and not honed by management.
Business applications build up "cruft" over time. Business rules tend to keep collecting and collecting until the behavior of the system becomes unpredictable. Nobody wants to risk cleaning it because they are afraid something might break. Or, there may be a business rule in there that solves a problem that the current staff did not know existed. The knowledge of why specific code exists might be lost. Users expect the behavior to be there, and are surprised if it disappears. A programmer might remove something that looked like a bug, to later find out that it actually served an important but undocumented purpose.
The challenge of programming in a business domain (enterprise) is mostly dealing with the interaction and expectations of humans as they relate to the machines. Whether one finds this boring or not probably depends on the person. Sometimes it is rewarding and sometimes it is boring, tedious, and frustrating as with most any jobs. Even rock stars get tired of drugs and all those gorgeous groupie babes...
| | View blog reactionsA general observation amongst many of my peers is that when they get home and start tickering with open source projects, they almost always gravitate towards infrastructure software whether it be operating systems, BPM engines, ESBs or ECM platforms. I have asked many of them why aren't they even noodling the creation of business applications in the open source space and receive lots of laughs.
Studying my own behavior, I think it is do to lack of interest in terms of wanting to capture domain-specific rules formed by others (aka the business community) where all the technical domains that open source has been wildly successful doesn't really require one to collaborate with non-technical folks like we do in an enterprise environment. Other reasons that I have ran across in my travels is that business applications while volumous in terms of lines of code and the need for structure tend to not be as intelectually challenging from an algorithmic perspective.
Open source could be wildly successful if it were to attack industry vertical challenges but could do so only when solutions to given problems are crystal clear. Business applications tend to have as a characteristic that there is no easy way to tell if your code is right without having to interact with lots of end users first.
Sometimes software developers have sufficient expertise and influence to suggest changes in business processes to make them more logical or efficient. Presenting ideas to a business domain expert requires skilful sales technique. Otherwise, you risk coming across as arrogant or pushy. In the business world being liked is often more important than being right, but techies often see the reverse, creating a culture clash of sorts.
Good solutions to tough change management problems are difficult to discover. It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales, and selling is generally an "intuitive" discipline. Thus, explicitness is often not expected and not honed by management.
Business applications build up "cruft" over time. Business rules tend to keep collecting and collecting until the behavior of the system becomes unpredictable. Nobody wants to risk cleaning it because they are afraid something might break. Or, there may be a business rule in there that solves a problem that the current staff did not know existed. The knowledge of why specific code exists might be lost. Users expect the behavior to be there, and are surprised if it disappears. A programmer might remove something that looked like a bug, to later find out that it actually served an important but undocumented purpose.
The challenge of programming in a business domain (enterprise) is mostly dealing with the interaction and expectations of humans as they relate to the machines. Whether one finds this boring or not probably depends on the person. Sometimes it is rewarding and sometimes it is boring, tedious, and frustrating as with most any jobs. Even rock stars get tired of drugs and all those gorgeous groupie babes...
