Managing mature it organizations



  • Hi Guys,  I know there are some "oldsters" on here like me, so I'd like to gather some opinions on a topic that's been bothering me. 

    When I first started in the business world, I noticed that some people left tasks undone.  In my enthusiastic youth I figured it was just sloppy work.  Then I noticed that nobody noticed and it didn't seem to be a problem.  A good example was security stuff, logging and monitoring breakin attempts, and also just general management like deleting obsolete files (letting the disk fill up) etc.  Also I noticed that often a person would be laid off or quit and either they would never be replaced and nobody would pick up the tasks they did, or when they were replaced the new person didn't pick up all of the tasks.  So again, more stuff went undone.  But again nobody noticed and things kept running.  Hmm. 

    Later, as  I matured and mellowed, I realized that not everything can be done to perfection so if it kept running without certain tasks being done, then maybe those tasks weren't as critical as I first thought.  Over the years, I've also learned that although it might look to me like a person is slacking off on his job, he's actually being distracted with too much work or other priorities placed on him by management.  It happens.

    Okay, years later and I'm happiily working on what you could politely call a "mature" software product.  Great, active userbase.  Although it's mature, there's no technical reason why it couldn't still have R&D or version cycles.  But we don't.  It's been stagnating with modifications made to it only at customer request, and as you know half the time the customers really don't know what they want.  Okay, life cycle of a software package, I understand that.  I don't like seeing an excellent product slowly die, but what can I do?  My management seems completely focussed on a competing product we've developed on a different platform that's newer and "better".

    What really gets me, though, is our customer service is also stagnating and slowly failing.  If you look at the helpdesk database you can see logs that customers have placed that haven't been addressed.  Simple things like wanting advice and even critical problems - it takes weeks or months to get anybody to look at them.   The guy who manages the helpdesk doesn't seem to make his team do their work, and HIS manager doesn't seem to make HIM do his work.  The guy above him doesn't seem to make THAT GUY do his work.  Either everybody is playing Freecell or they're working on some other unrelated tasks.  (Since I don't have management's Big Picture, I don't know what everybody's working on, but I like to give the benefit of the doubt.)  It's very embarrassing and frustrating as heck.  Customers pretty much call me directly for any problems and questions they have, and if I can't help them referring them to the helpdesk gets us nowhere.  Our tiered support strategy has pretty much broken down.



    The people who run the helpdesk have been there for years but I've heard recently that they don't know our product or the platform.  WTF?  I can't quite believe that.  What I think is happening is that all the really GOOD people have moved on and all the mediocre people are still there just coasting to get a paycheck.  There are maybe three of us who do care and have pride in workmanship and try to give good customer service, but we can't carry the load of around 50 customers between us.  Since it's a mature product the helpdesk people never get to learn anything new and they aren't interested in being challenged (or they would have moved on, right?)  Since it's a mature product, management is reluctant to put any more time or money into it than is absolutely necessary. 

    So what do you think?  Bad management?  Normal software lifecycle?  Fixable or lost cause? 



  • @jetcitywoman said:

    Normal software lifecycle?

    I wouldn't say normal, but classical, a pity, i know.

    The thing is, at some point, when you have a large userbase, i noticed that management doesn't really care about making necessary changes or improvement to the products, mainly because it would cost more money than what the current userbase ( understand, more or less trapped userbase ) is making without changing nothing.

    dunno if it's the same for the other people lurkin' around here, but i've seen such things already.

    I don't know about you, but i just can't stand telling lies to a customer when they ask for critical changes ( for them) and i know nothing will happen.

    for the poll, I would say, lost cause.



  • Management probably does not want big changes in the mature product, since they would rather sell the new (competing) product. They want to let your product die slowly. Let it die fast and customers turn their backs on your company. Keep it alive and you'll never sell the new product. Pity, but that's the way it is. Anyway, a helpdesk that doesn't help is a waste of money.



  • @jetcitywoman said:


    The people who run the helpdesk have been there for years but I've heard recently that they don't know our product or the platform.  WTF?  I can't quite believe that.  What I think is happening is that all the really GOOD people have moved on and all the mediocre people are still there just coasting to get a paycheck.  There are maybe three of us who do care and have pride in workmanship and try to give good customer service, but we can't carry the load of around 50 customers between us.

    And in all probability you are also going to bail on it. 


    Bad management?

    Combined with a complete lack of realistic planning, yes. 

     

    Normal software lifecycle?

    Yes. The software lifecycle (theory):

     

    The software lifecycle (practice):

     

     

    Fixable or lost cause? 

    There are no recorded instances of it being fixed, despite many attempts. Now you understand why it is that every time you try calling a megacorp, you get nowhere.



  • Bad Management? I'm afraid not.

    Mature products are very costly to maintain. Making changes takes much more planning, regressive testing and field tests than fresh software. Sometimes, what is technically a bug may be exploited by a certain users - so you simply can't fix it. Unless you're a 500-pound gorilla like Microsoft, SAP or Oracle you can't impose your will on the customer base.

    Good management is making lots of money - not making good software. In business software, maintenance revenues are the primary source of income. Maintenance and customer lock-in are tangible assets. The valuation of a company (read: IPO, stock options) benefits greatly from those. Investors will never be able to judge software good or bad. The bottom line is all that counts.

    Good management is the art of dying profitably. Milk 18% maintenance. Slash the workforce. Outsource.

    Bad management is making software that actually does what the customer really needed.

    Sad, but true.



  • @asuffield said:


    We have a printout of this on the wall. 



  • @JvdL said:

    Bad management is making software that actually does what the customer really needed.

    Sad, but true.



    Bad management is management that never goes against clients.
     



  • @JvdL said:

    Bad Management? I'm afraid not.

    Mature products are very costly to maintain. Making changes takes much more planning, regressive testing and field tests than fresh software. Sometimes, what is technically a bug may be exploited by a certain users - so you simply can't fix it. Unless you're a 500-pound gorilla like Microsoft, SAP or Oracle you can't impose your will on the customer base.

    In principle, I agree with you, but in practice this doesn't seem to be the case here.  This mature product is for a specific and limited business sector.  We had this weird but flexible strategy that we put the source code for our product on each customer's machine.  When they want bugfixes or enhancements, we do it via dialin or sometimes in-office directly to their systems.  (They do have separate "test" and production systems to facilitate this safely.)  And of course, this is done in old top-down structured languages (assembler and an enhanced version of Cobol).  That makes us pretty agile.  We don't do regression testing but we test as thoroughly as we can, and we don't have to worry about a modification breaking things for other customers.  Of course there are other problems with this.  But in practice I see me and my coworkers completing projects in quarter of the time it takes our other product division with the competing product who DOES use modern software methodologies and languages.  We tend to have much less downtime for our customers when doing major enhancements, which includes new interfaces and platform changes.  We're old but actually pretty impressive.

    @JvdL said:

    Good management is making lots of money - not making good software. In business software, maintenance revenues are the primary source of income. Maintenance and customer lock-in are tangible assets. The valuation of a company (read: IPO, stock options) benefits greatly from those. Investors will never be able to judge software good or bad. The bottom line is all that counts.

    Good management is the art of dying profitably. Milk 18% maintenance. Slash the workforce. Outsource.

    Bad management is making software that actually does what the customer really needed.
    Sad, but true.

    Yep, I agree 100% with you here.  I have heard from our project managers that our mature product projects are more often profitable and our little segment (officially called customer service in our division) brings in more money than the new competing product (officially called product engineering).  I've heard that the PE group is subsidized by other unrelated portions of the corporation while we're not.  To me that says that we're dying because we're mature which is a bad thing in the IT industry, but the competing group is also dying because they can't seem to find a way to be profitable.

    In our heyday in the 1980's we had something like 80% market share for our software in our market segment.  It's declined dramatically and now we're something like 10%.  I think being purchased by large corporations and then mergered with other large corporations we've lost the knowledge and focus of our market.



  • I've been thinking about this overnight.  I guess the problem is:

    *  the product I work on is simply dying.  It's over 30 years old and although it was finely engineered right from the start, it's probably not possible to support it "properly" as it deserves.  We'd never find new programmers willing to learn Cobol, for one thing, and porting it to a newer language like C would be reinventing the wheel and that's really what our competing product was intended as anyway.  So it's dead Jim.

    *  I can keep working on it in maintenance mode, but knowing what I do about how it's dying, I would have to set my ethics and ambitions aside.  For example, I have all these grand ideas of new features, new challenges for us programmers that will never happen unless a customer is willing to purchase them.  It will never happen.  Also, I simply can't do a mediocre job just coasting by to get a paycheck. 

    *  I'm very willing and able to learn new languages and technologies and refresh my skillset.  But at age 43, who will hire me?  I can stay at this same company and learn the new skills in my own free time and somehow try to justify a change to a different job in the same company.  That's very do-able.  I can also start positioning myself for promotions into project management, although I've seen the crap my PM's have to wade through and it's not pretty.

    *  The article on the main page about the failed FBI project intrigues and bothers me.  People have been working on methodologies and solutions to failed projects for over 20 years now.  Why do we keep making the same mistakes over and over?  I'm not saying it's easy, corporate politics alone are enough to break a project.  But there is certainly alot we can control and do better, but we're not (as an industry).  I see a market there for educating companies and IT professionals on how to correctly run a project.  Some sort of business analysis consulting thing, but it's not clear in my head yet.  I've also seen in practice how regular business analysts are brought into the companies I've worked for in the past, do a terrific job of outlining problems and solutions, only to have their work completely discarded by company management.



  • @jetcitywoman said:

    We'd never find new programmers willing to learn Cobol, for one thing, and porting it to a newer language like C would be reinventing the wheel and that's really what our competing product was intended as anyway.

    Ahem... Although C definitely still has its places, it would probably be a terrible choice for a Cobol program to be ported to. I can only hope you have meant C# and made a typo ;-)

    Anyway, your situation calls for a skunkwork project. E.g. a Cobol parser that outputs readable C# code. Make one that works well for your project, port your program and show those "product engineering" guys who's boss. I'm pretty sure your existing customers will appreciate a new version that mostly looks and feels like the old one.

    At least you can learn new technologies which might help you if your management finds out and doesn't like the idea ;-)
     



  • Parsing Cobol into C# code? I can only assume you're phishing for new material on this site.



  • @ammoQ said:

    Ahem... Although C definitely still has its places, it would probably be a terrible choice for a Cobol program to be ported to. I can only hope you have meant C# and made a typo ;-)

    Well, it was just an example.  I guess I should have put <insert modern language here> for the literalists in the audience.  ;-)

    @ammoQ said:

    Anyway, your situation calls for a skunkwork project. E.g. a Cobol parser that outputs readable C# code. Make one that works well for your project, port your program and show those "product engineering" guys who's boss. I'm pretty sure your existing customers will appreciate a new version that mostly looks and feels like the old one.

    At least you can learn new technologies which might help you if your management finds out and doesn't like the idea ;-)

    Oops, what I didn't mention was that we're one of those huge corporations with SOX-style requirements for time reporting.  In other words, we have to charge our time to existing projects and they don't give us any overhead charge numbers.  So that's why if a customer doesn't buy it, it doesn't get done.  I'm actually struggling right now to find a way to rewrite an interface that was crappily done but is "good enough".  I discovered this summer that the interface was "the way we always did it", and nobody in my company had been paying any attention to the fact that the 3rd party software we interface to has expanded and grown over the last 10 or so years.  It's extremely embarrassing, but apparently only to me.

    And despite the impetus toward obsoletion, I'm managing to still learn new technologies.  I've been able to dabble in XML on occasional projects.  But mostly in non-work hobbies, I've learned HTML, and a little bit of javascript and SQL.  Since our system interfaces to all kinds of hardware and 3rd party software, I'm always happy to learn new things by working on the interfaces.



  • @jetcitywoman said:

    Why do we keep making the same mistakes over and over?

    People want to believe. They think that being 'optimistic' is a good thing. They assume that things will go well, and so when things inevitably go worse than expected, they aren't prepared to deal with it. They are emotionally incapable of recognising their own limitations and errors, and so they never do anything to avoid or correct them.

    Let's assume that somebody is planning a project. They go and present their idea to a room full of 30 engineers. They quickly get 29 responses pointing out the flaws, and 1 guy who says it'll all work fine. That last guy is put in charge of the project, which promptly breaks in all 29 predicted ways.

     

    But there is certainly alot we can control and do better, but we're not (as an industry).  I see a market there for educating companies and IT professionals on how to correctly run a project.  Some sort of business analysis consulting thing, but it's not clear in my head yet.


    Substitute 'engineers' with 'business analysts' in the earlier paragraph. Exactly the same thing will happen. The only people who survive as consultants are those who tell the executives what they want to hear, not those who give them good advice.

     

    Most people are fundamentally stupid. Even if they are capable of thinking a problem through, they just don't bother. 



  • @jetcitywoman said:

    *  I'm very willing and able to learn new languages and technologies and refresh my skillset.  But at age 43, who will hire me?  I can stay at this same company and learn the new skills in my own free time and somehow try to justify a change to a different job in the same company.  That's very do-able.  I can also start positioning myself for promotions into project management, although I've seen the crap my PM's have to wade through and it's not pretty.

    Sounds to me like a change in venue is in order.  You're already thinking like a manager, so get a management job.  Most of the dev managers / VPs I know are in that age range and have the life experiences necessary to understand how to take care of business; unlike the current crop of 20+ year olds who need their hands held and ego's stroked for everything.

     

     



  • Yeah, I am slowly gaining the maturity and business sense to become a manager.  I don't think I'm there yet, though.  For one thing, diplomacy escapes me and I HATEHATEHATE politics.  Plus I would miss "getting my hands dirty" in the technical stuff.  For example, on the interface I mentioned earlier, I've pretty much decided that I can use the corporate inefficiency, hypocrasy, and stupidity against itself and just do the work and then charge it to random various projects.  After all, when we are standing out in the parking lot for an hour during the stupid fire drills, management tells us to charge the time to whatever projects we happen to be working on.  So why can't I do the same with real work?  I've accidentally discovered with a smaller pet project, that I can do some cool useful work without permission and then just show the finished product to them and they're like "cool, you're so amazing to have done that not on company time!" 

    At this current place, we have two types of management.  The project managers, sort of like the peons of the management structure, but they're the ones who actually do real work.  They also get all the crap from customers, employees, and upper management.  It seems like they're the first ones laid off, even before us programmers.  They're always getting their customers rearranged for them, which is about as popular with the customers as it is with the PMs.

    Then there's upper management.   They make BIG Buck$$$.  They are constantly reorganizing themselves and their on-paper organizations.  They're constantly being hired and leaving the company, both with much fanfare.  From everything I can see, they spend their time looking at spreadsheets and having meetings to develop "leadership" campaigns to do things like the poster in the lobby that's autographed by them all attesting to something like "integrity in leadership".  Or some such mealymouthed crap.  (IMHO, if a manager doesn't have integrity, he needs to be shot and then fired, simple as that.  You don't need to waste time developing signs with pretty mottoes and then having an autograph party.  I think they think that when we employees see it, we'll think "Hey, Joe UpperMgr has integrity!  Man, then I will too!")



  • @jetcitywoman said:

    Yeah, I am slowly gaining the maturity and business sense to become a manager.  I don't think I'm there yet, though.  For one thing, diplomacy escapes me and I HATEHATEHATE politics.  Plus I would miss "getting my hands dirty" in the technical stuff.  For example, on the interface I mentioned earlier, I've pretty much decided that I can use the corporate inefficiency, hypocrasy, and stupidity against itself and just do the work and then charge it to random various projects.  After all, when we are standing out in the parking lot for an hour during the stupid fire drills, management tells us to charge the time to whatever projects we happen to be working on.  So why can't I do the same with real work?  I've accidentally discovered with a smaller pet project, that I can do some cool useful work without permission and then just show the finished product to them and they're like "cool, you're so amazing to have done that not on company time!" 

    I'm not a manager or anything, but besides my own projects i'm currently managing a few where i basically only communicate with the customer and the guy(s) who do all the work. And i totally understand the tingling feeling, because when i'm talking to the customer about new features or bug fixes or whatever i can already see how i should alter the code and the structure, or where the bug might be located. However since i absolutely hate to be micro-managed myself i always try to get some discussion going about how to implement a new feature with the guys who will actually do it.

    My finding however that it really varies from person to person on how much their willing to pitch in. I even have a sneaking suspicion that one guy actually just says nothing until i tell him on the code level how i think it should be implemented and then he does just that. Which i find annoying because i hate working like that.

    Making improvements management hasn't heard of or wouldn't grant is one of my favourite things, although i'm a bit of a sucker and tend to do that at home after hours or in the weekend. I know from the whole business/employee perspective it's stupid, but hey i like doing it so it can't be all bad.  


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.