» VIEW ALL POSTS Dec 10 2007   12:50PM GMT

Corporate IT or vendor IT: Which is like a dog’s breakfast?



Posted by: Clinek
Tags:
Managing an Oracle shop
Oracle development

SOA guru Steve Jones recently wrote an amusing riposte to a blogger who warned budding developers not to go into corporate IT because it was “soul suckingly bad.”

The original post, from coder Joel Spolsky, argued that corporate IT development is not a fulfilling career because:

1. You never get to do things the right way. You always have to do things the expedient way. . . . You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough. Get out of there and onto the next thing.

2. As soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship . . . You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk.

3. [Unlike in corporate IT], when you’re a programmer at a software company, the work you’re doing is directly related to the way the company makes money. That means, for one thing, that management cares about you.

Steve responded by saying that Joel must have had a bad experience at a crappy company. “The real reason to me that corporate IT is a great place to work,” he says, is that “if you are good and have good communication skills, you can actually see what you do makes a difference. . . it’s corporate IT where the real achievement is. Software vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.”

Plus, he points out, in a corporate setting, there’s better “societal balance — by which I mean women.”

In-house developers might be an endangered species anyway. A Ventana study last year found that many companies prefer to buy, for example, off-the-shelf business intelligence applications rather than build them.

What do you Oracle developers think?

Cheers, Tim

3  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Clinek
    Both of you are generalizing way to much. To a developer, only the specifics of your current and past positions matter. Other peoples experiences at other companies, have no bearing. I have done both, in-house developement and product development, and had good experience with both. Yes, in-house you get swifter gratification to see the customer use what you develope, and as a product developer, you get the satisfaction that hundreds/thousands of users are using your product out in the work place. But in the end, the purpose is to help the company make a buck so you can make a buck. Remember, to learn your business, and do what you can to help your companies bottom line. That is why the company is in business, and that is where you satification really comes from. Unless you are Dilbert, then you are just hosed.
    0 pointsBadges:
    report
  • Clinek
    I have worked the last 24 years in Corporate IT and have had a lot of fun doing it. Because we have multiple developers working on different projects there are some here that would probably agree with the Spolsky. I am not one of them. I believe that it depends first on the individual developer and next their supervision. If the developer takes the initiative and can convince supervision/management, they can find ways to improve their product. I always take opportunities to improve the look and feel of my applications when doing maintenance enhancements and bug fixes. I am never satisfied with what I've produced even if the end user is.
    0 pointsBadges:
    report
  • Clinek
    It is really a more complex issue than corporate versus software vendor environments. There is a growing mentality in IT called web speed development. As David J. Anderson states it: "Increasingly we are asked to deliver more and more complex software for use over the internet, in shorter and shorter product cycles." This mentality leads to the issues mentioned by Joel Spolsky and it is happening in all IT teams. The need for upfront analysis, proper project management, and quality coding get overturned by the "Good enough - get it done now" philosophy. What can developers and DBAs do? As Bruce suggested, we need to learn to manage upwards to "educate" our management on why we need to do it the right way and not necessary the fast way. We also need to figure out ways to adapt to or alter this mindset. A few suggestions from my experience: 1 - Use the Scotty Principle in estimating. This helps you build in time to do more development. Or - it covers you if unexpected problems occur. However, you will have to get your management accustomed to the new estimates. If projects were taking 100 hours and now you say 200 hours, management will balk. Start adding hours to every new project until you get to a workable level. 2 - Learn to be a salesperson about your software (your product) so that you can convince your management, in language they understand, that more time/features are needed. For example, you saying that the software needs to look better does not play as well as "customers will dislike using the software because it is difficult to undertand the screens". This translates to unhappy customers/users who complain to managers rather than you wanting to make it look "pretty". Learn to spin to accomplish your goals. 3 - See the big picture. Another reason that non-IT people rush us to get our software done is that they feel we don't understand the pressures they are under. I disagree with a previous poster who said "only the specifics of your current and past positions matter". Being more tuned into the overall goals and needs of your company is exactly the way to help the bottom line. For example, as a developer, I may have to rush out a software product that is less than I would want - but the company could be fined $1 Million if I don't. If the non-IT people (or customers) feel you really understand their problems, they work with you better and they are more willing to take time to get it right. While individual managers may care about their developers, the general view of us is no different than the assembly line workers. Management doesn't want to know about how we operate "our machines" to produce their product - they just want it out as soon as possible. It falls on us to figure out ways to control these expectations and improve the process. Our input may go unheeded - it may get us fired - but it may just make a difference. Each one of us has to figure out how to manage ourselves in our companies - or look for another job.
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: