Slashdot Mirror
How to Stop the Dilbertization of IT?
Alien54 writes "In the simplest terms: too many IT workplaces have become Dilbertized -- micromanaged, bureaucratic and stifled creatively. It's become an environment where busy work is praised and morale is low. How is it possible to bring IT's appeal back? 'IT professionals that have worked in the field for a long time often speak about a shift in their work where they have gone from tossing ideas back and forth to make for better technology solutions to fighting fires all day. "There's less emphasis on creativity, and more on maintenance. Tweak this, work on this ... In being reactive not proactive, everything is a crisis. Something has to be done right now, putting out fire after fire, going a long way to making IT a less pleasant environment," said Skaistis. Beyond making for a unpleasant work environment for the techies already in-house, this firefighting serves as a warning to potential recruits: you will not like this job.'"
Ten years ago the internet was just coming into the public awareness, there was tons of infrastructure growth, and lots of issues that didn't have very clear cut solutions.
These days most of the growth has slowed, things have been tried and proven or cast aside, and we're transitioning to more of a steady state environment. Even where there is lots of growth we know how to handle it and growth has become routine too.
"Prefiero morir de pie que vivir siempre arrodillado!"
Welcome to the world profiled, catalogued, and databased such that every person is pigeonholed into their own individual spreadsheet cell--and heaven help them if they should try to take up more space than the metaphorical spreadsheet maintainers (the stock brokers, analysts, and accountants) have allotted.
the NPG electrode was replaced with carbon blac
1. Many IT shops are in financial institutions or other businesses where systems are handling millions or billions of dollars. In that situation you don't want a whole lot of creativity. Every time you change code you introduce risk, and the more money at stake, the more risk-averse you are.
2. I'm not sure creative new techologies are needed right now. A lot of creative new technology emerged during the dot-com boom, and the tools and talent were subsequently bought up cheap by corporate IT shops. The IT industry still has not digested the technology it already has.
3. If you want creativity, shun the larger shops and go work for a startup, or start one up yourself.
1) IT folk need to understand that they are there to solve business problems, not IT problems, and need to leave a little more about business, instead of making business people learn the IT language.
2) Currently, if you're good at your job, you will be promoted to management in IT, which means you will no longer code, and have to learn to manage people. What would be better is to create a senior position that has the money of management, but allows a great coder to remain a great coder.
3) People in the organization have to be punished for causing problems that they look to IT to fix. Due to others lack of planning, we're constantly having to pull micicles out of our asses. But while we take the risk, others get the reward. This has got to change.
Just my opinions...
Companies are moving more and more to Dilbertization. Why? Because they want classic managers in charge of IT. In the early days, IT managers were kind of the strange ones in the management pool. It was because they were IT guys that were promoted into management, despite formal management education. Most large companies hired, from outside, their managers for other departments. Those that were hired from inside were "management material".
Companies now want to get away from the IT guy as manager. They want the IT guy to be a specialist. Managers aren't specialists. This means, the tide is toward managers who have 20,000 foot view of IT. Sweeping the tide back with a push broom would be easier than stopping the trend.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
This is a predictable result of managing tons of users who all want to treat a complex machine that can perform millions of functions as though it were an appliance like a toaster or a microwave. The "I just want it to work but not if that means I have to learn anything" crowd are high-maintainence users when compared to someone who knows the utility of understanding the use of the tools you need to do your job.
Think about it this way. A car does only one thing, and yet you are required to obtain training and a license before you are allowed to use one. The idea that you can use a general-purpose device and not have to learn anything about how it works is an absurd pipe dream that has generated a lot of profit for the likes of Microsoft, but there is an expense to that idea and the expense is shouldered by support staff who act as a surrogate for the knowledge that the users did not want to learn. Much of IT really has changed from finding creative technical solutions to babysitting "permanent n00bs", you know the ones who can use a machine for five years straight and somehow manage to never learn anything new about it. Not everyone wants to be a tech? I'll buy that, but not knowing much about the tools you need to do your job and depending on someone else to pick up the slack doesn't sound very responsible, and never picking up more skill over the years, well, that takes work.
I used to be in the IT industry, and it is precisely this situation that made me decide to get into another line of work. As a hobby, I can really enjoy computing. As a profession, I became so sick of the willful helplessness (when all the tools and information are available and people don't learn anything simply because they don't care, but when there's a problem they sure do care then) and pure laziness I kept encountering that I ended up deciding that it wasn't for me, that there are less stressful ways to earn a living.
It is a miracle that curiosity survives formal education. - Einstein
the NPG electrode was replaced with carbon blac
While this seems like a very limited solution, I would agree. I worked for a Big-5 and noticed month after month that propz went to people who could RESOLVE issues (usually issues created by their own bad coding.) Little propz went to people who simply didnt create issues (by designing properly, testing well, etc.) I reduced my testing one quarter and spend less overtime at work. Naturally bugs resulted. I was promoted for resolving these issues. I quit tech work and became a business analyst. I couldnt work in a position where people were rewarded for being idiots. Though i'm sure this was very particular for this group in a particular Big5, just some food for thought. Basically, what are management's expectations?
The answer to your question is that for in-house projects, IT needs to be separated into distinct engineering and operations groups.
.war or .ear file just like you would for any other customer. As a developer, operations should be your only customer, and your relationship with them should be the same as the relationship you would maintain with your most valuable and critical customer.
IT Engineering is what the OP obviously favors. Designing new technologies, building better solutions to existing problems, and increasing productivity through these incredible meta-tools we call computers. IT Operations is about taking these technologies, cataloging their shortcomings, and doing what is necessary to implement them and keep them implemented. Engineering is about the introduction of new ideas; Operations is about the constant war to keep those ideas safe from entropy.
Often, these goals are in direct conflict. It is only natural for a solution developer to recognize the shortcomings in their product and want to fix it. It is in the best interests of operations that a stable server not be changed unless absolutely necessary, and then only when the changes have been thoroughly tested, put through miles of red tape and human business process, and signed off on by people whose jobs are on the line if the application goes down. The idea that you can write a program and be the person who runs it most effectively is a false one in any mission critical application. When there's money on the line, red tape and paperwork is the only way to make sure that it keeps flowing.
So to be successful in IT, we on the one hand need developers who are free to try radical new ideas in an environment that rewards creative solutions to entrenched problems, and on the other hand we need a static environment ruled by business process and red tape, which stifles unproven concepts and chokes creativity. The only solution to this is to separate these groups completely, and have development treat operations as a very stodgy customer. Too many companies don't realize that this split is necessary to maintain their financial longevity, and have the same people who develop their applications responsible for their day-to-day operations. This situation not only leads to frustrated development staff who feel creatively stifled, it is also in the long term project suicide. In-house developers should not only be relieved of the responsibility for running their code, they should in fact not even have logins to the servers on which their code is running.
Professional standards of code release need apply, too. It's not enough to release code to production via CVS checkout, you need to write an installer with an uninstaller and an upgrade path, just like you would for commercial software. It's not enough to run an ant build on your server via an NFS mount back to the depository, you need to compile a
But one person wearing the development and operations hat? That leads to nothing but frustration, burnout, entropy, and failure.
Even Jesus hates listening to Creed.
That's what the
"Debt" is a ten thousand year old playground game.
the NPG electrode was replaced with carbon blac
and focusing on root cause, not the current fire. Get things working again and then take the time to find out why things went wrong. 85% of service interruption is caused by human error. Companies and techies spend money and time constantly fixing the same things over and over again. If you take time to find the root cause, using ishikawa and other techniques you can actually stop running from fire to fire. One huge thing though is that a LOT of IT people like being the firefighters because they get more glory, and unfortunately a LOT of managers don't reward employees who aren't firefighters, and fix problems before they impact production. When things are quiet, that means that someone did their job right. Proper problem management will decrease calls to the service desk (helpdesk) and decrease first level resolution rates- you're not solving the same problem over and over again. A knowledgemangement system helps with this.
d ent_Managementl em_Management
d =19
Check out the ITIL definitions of problem and incident management:
Problem Management-http://en.wikipedia.org/wiki/ITIL#Inci
Incident Management-http://en.wikipedia.org/wiki/ITIL#Prob
Another good one- http://serviceinnovation.org/
I've seen Greg Oxton from serviceinnovation speak and here's a link to where he describes the true impact of errors on the user community. (starts really getting into impact on slide 11)
http://itsmf-tampabay.org/WordPress/?attachment_i
My 2 cents
So is that a good or bad thing, and good or bad from who's point of view?
Mac OS X and Windows XP working side by side to fight back the night.
The problem is that many (most?) companies nowadays see programmers as commodities, creativity as risk, planning and careful deployment of systems as expenses. They have managers that don't know anything about technology, deadlines impossible to meet, no recognition for merit and talent. The consequence is that systems crash all the time, "workarounds" are the rule and the good professionals are overloaded with work to make up for all that people that work with them that don't have a clue.
With such perspective ahead, it will be no wonder if in a near future the best brains will go to finance, law or any other profession that may offer what IT used to do.
The problem is that IT has been taken over by Business School Product. They have no grasp of science, no feel for aesthetics, they only have feel for next quarters numbers and covering their ass. This is what Business School teaches. One needn't know anything about an industry in order to manage it, Business Schools build this into their Product. They will never, ever learn a new skill unless it is something useful for climbing the corporate ladder. The best thing IT can learn is to weed Business School Product out. Dilbert's boss is hiding in every last one of them.
This is silly. "Creativity" does not mean "being a cowboy." A creative solution can be implemented carefully, after thorough testing and validation. On the other hand, a non-creative solution can be implemented in a sloppy and haphazard manner. Handling large amounts of money means you need to be careful and disciplined when you design, test and implement a solution. It doesn't matter if the solution is creative or not.
I disagree with your second point, too. Even if I grant that "the IT industry still has not digested the technology it already has," that doesn't mean that existing technologies solve the problems that people and companies have. It would be nice if they did, but it's just not realistic to think so.
Your third point, though, is right on the money.
In those "good old days" alluded to in the story, I.T. as a corporate-wide monolithic structure did not exist. Technology was handled by various business units on an as-needed basis. The supposed efficiencies of a corporate-wide I.T. have never been evident to me, but the dangers of an entrenched class of PHB I.T. management has been well demonstrated. Disband I.T., fire the C.I.O., make technology projects accountable to the business units, and you'll go a long way to solving most of your problems.
Of course, if the "uncreative" 1000 line version is 7-times bigger for the right reason, it is avoiding clever-clever tricks so it is easy to determine that it does what it's supposed to and it's easy to maintain.
The most bloated, boring and uncreative code I have ever seen in my life was a safety critical system that had the potential to kill hundreds of people if it went wrong. It might have been bloated, boring and uncreative but it was also blindingly obvious what it did, how it did it and that it did it right. There is a place for creativity in software, but there are also some places in which creativity can be a bad thing -- and as well as the safety critical domain, the financial sector is probably one. Sorry folks, but I think the place for creativity is likely to be in novel applications, not the mainstream, and as somebody else has pointed out that means that the interesting stuff is in the small software houses.
Quidnam Latine loqui modo coepi?
Dilbertization is INEVITABLE in any hierarchial organization. There's nothing whatsoever you can do about it.
It's causes are ultimately all within human nature. Starting with the technologists themselves, they're all in competition with one another. Each wants to be recognized as the alpha geek. Furthermore, some are lazy and some are energetic. the lazy ones hate the energetic ones because they make them look bad. The energetic ones hate the lazy ones because they're not carrying their weight. Finally, the TALENTED technologists are repulsed by the thought of being promoted into management, but the inept ones love the idea, as do the closet fascists.
The professional managers, middle-managers, "project managers" (ha!) and other undead minions of all standard IT organizations are just as dysfunctional. Secretaries are sullen, convinced that everyone thinks they're stupid (in some cases, this is astute on their part). Project managers, like the fawning little lap-dogs they are, tell management whatever they want to hear, often totally fucking over their staff by agreeing to ridiculous deadlines that cannot be met. Middle managers often know nothing whatsoever about technology and run their areas according to whatever management theory is currently in vogue. Worse, they often rate employees by how well they schmooze, not how well they code. Nepotism is rampant. Other minions, like managers selected to represent users in design meetings, often are in way over their heads and only want to cover their asses and contribute enough to meetings to LOOK as though they've got things under control.
If you work in a private company, you can be fired at any time for any reason, and often your fate is totally arbitrary. Knowing this, you MUST always keep your eyes open for new jobs; companies are like women, they never want available developers, because they think there must be something wrong with them (so they stick to poaching from other companies). If you think you're going to be fired, you have to start interviewing right away before you lose that "I'm still employed" cachet. And you have to know who is a "special friend" of which bigshot so you don't accidentally step on the toes of so-and-so's asshole cousin and prematurely end your career.
If you work in civil service, you can't be fired easily but this means that you always end up with at least a few totally useless idiots in your department. They KNOW they can't be fired, so they just sit around like barnacles, slowing the whole boat down. At most, the part of the staff that'll actually be able to DO anything will be 25-50% (and they'll be bitter and snarky about it -- can you blame them?). The rest are all deadwood. The same is true for management! You see these ridiculous men in their fifties, already mentally a senior citizen, just waiting to retire at 55. They DREAM of a "25/55" deal and talk about it with anyone they can pidgeonhole. Finally, because the deadwood just wants to be left alone to play some stupid downloaded Windows game (which probably was a trojan) they'll pretend they're really busy to the boss and you won't be able to get ANYONE to agree to let you build anything, even if it would make the whole department more efficient.
The whole system is completely, hopelessly, irrepairably FUBAR. It's a clusterfuck of legendary proportions. The only way to survive within it is to make yourself invisible and get your work done as efficiently as you can, while not getting drawn into any politics, never suggesting anything, and never volunteering for anything.
NO CARRIER
Too late...
Creativity?
Do you see the beauty in a well-designed UI? The pleasure of using a properly designed input screen? Is art a value proposition? YES! So what's the value proposition in IT? Greater value to the organization? Compliance with the laws and regs? Zero-Day Start?
If you do really, really well, and solve problems before anyone notices that a problem was coming, do you get recognition? Is that the creativity gap?
It's hard for me to see the creativity option in technical analysis. I respond to problems, resolve the issues, get my clients back to work. Even when I determine the root cause and send the developers off to fix the product, I feel more like the Angel of Death than the Deliverer. My manager encourages me to be 'proactive'. Like, do I ask my clients to break stuff so I can offer them the fix I already have waiting? Do I call them and ask why they aren't having trouble?
IT can be creative. When your CEO demands a logging tool so he can know who is surfing pr0n on work time, you can get creative and recommend first publishing a top-ten or top-hundred list of sites visited. Things measured improve...
Of course, those opportunities are rare. I suppose even Monet had slow days...
-rick
deleting the extra space after periods so i can stay relevant, yeah.
Sounds like your friends either suck at their jobs, and thus don't expect to ever be able to get another one, or they are gluttons for punishment. If your bos expects you to work 70 hr weeks without compensation, or be on call 24/7, or do impossible projects without any money, you should just quit. There are always other jobs out there if you are good at what you do. It sounds to me like your friends will let people walk all over them and their managers know it. Why hire an extra employee when you can get the ones you have to work for free? I don't care if you make $10/hr or $1000/hr, if your boss treats you like shit, and has no respect for you, quit and find a job somewhere else. The only people who can't do that are the ones who managed to sneak their way into a job they weren't capable of doing in the first place, and they will do anything to keep it because they know ir probably won't happen again.
Some people get disproportionate amounts of credits for stuff, and those tend to in two categories, people close to executives and people who get approached by customer executives first.
Too many times I've seen a technical person get shipped off for *months* to work on the technical details of achieving an unreasonable schedule. They'll work long stretches of 7 day work weeks at 10-12 hor days to make up for overly-optimistic schedules hundreds of miles from home and family. They come back to a pat on the back and maybe a 50 dollar gift card to a restaurant (though admittedly, their room/board/travel for the months away were covered..).
Meanwhile, the project manager who set the insane schedule, kept their ass comfortably in their desk chair for 9-5, M-F days, for the most part just asking the technical guy 'how close to done are you', and repeating that data to customer executives and their own management chain. This project manager gets promoted in recognition for their 'stellar work to make it happen'.
Same with sales to a degree. Some sales situations, particularly in technical sales, requires a fair amount of work. Other times, I've seen cases where a customer without provocation approaches sales and says "Here is a very large, specific set of stuff and I am buying from YOU, place the order". In making it happen, sometimes its a tall order and technical people are called in, working long weeks of long days far from home. At the end, a note comes out congratulating 'all who made it happen', and then lists everyone, the list more often than not includes some executive who barely has a vague notion about it happening at all and the salespeople who in some cases just did the equivalent of forwarding a customer note verbatim to a sales system. Technical people are just interchangeable cogs that were simply there regardless of the miracles they pull off.
People removed from the direct customer pay-out and from higher-level managers just frequently get overlooked. I've seen this in several companies and I learned a long time ago volunteering to overextend yourself just ends up screwing me and making some undeserving person look good, so I refrain from things that I know will end in travel and long hours. What little credit there is to be had for going 'above and beyond' for many doesn't scale up at all beyond putting in just a little extra effort.
XML is like violence. If it doesn't solve the problem, use more.
Dude, if you or anyone you know works in such situations... get the HELL out of there. If you have any of those skills, you can start anywhere but there. I currently make around 70k and I work from 8-5 and I take 1 hour lunch break and scatter 'plumbing' breaks throughout the day. They know that if they lose me, they lose a lot of money because of all the custom work I am doing. They can't outsource me, because I'm the guy they outsourced to.
If they really know all those protocols, let the company outsource (or threaten to), they will probably end up being the contractor on site doing the job, but then outsourced. I worked direct for a company, got fired because I didn't want to bend to the advertising manager's every whim (very archaic and bureaucratic company, and he was good friends with the CIO), and I got the next week the offer from a company they were forced to outsource to, to go back there and continue the same job, I declined, but you see what happens when managers screw you. Oh yeah, it was a Fortune 500 company and due to this and many other reasons, they are in progress of being taken over by competitors.
Another job I did was sysadmin and I was there 2 years, again the CEO was Dilbert's pointy haired boss and everything had to be done whenever he felt like it. I left as did many others. Their whole helpdesk was replaced within a year after I left (I was the first and showed everyone that you CAN get a job elsewhere these days), their 'custom' programming team (6 persons; programmed a totally custom ERP system tying in to their server park, website and customer database) got together, quit simultaneously and started their own company and now the original company has to source the programming out to them, they do whatever they want on their own pace and get paid big bucks for it.
I constantly get calls and a lot more e-mails with offers because I have the knowledge. Skilled IT workers are in demand, most outsourcing projects failed horribly (what good is an internal IT department that doesn't/barely understand the native language and is located in India) and companies are hiring massively to build up their IT departments again although most of them are on contracts these days. I love being on contract, you get to do a job you like, you do it good and nobody is going to oppose you because you're expensive ($58/hour or more). If you deliver, you can stay longer and you don't have to put up with any of the salaried bullsh*t, because if they call you at night, or ask you to do some extra, you ask, should I put this as overtime (rate x 2.5) or can I come in later tomorrow.
But really, I'm not putting up with the 24/7 crap (unless I get paid big bucks for it and I don't have a partner to live with) or unpaid overtime anymore. They can say you're going to be outsourced, but actually, these days YOU are in demand, those threats are so 2000.
Custom electronics and digital signage for your business: www.evcircuits.com
and passed up for other jobs as a result. Many companies are scared of techies who know more than the little box they expect them to fit in. They know they'll become unhappy fast, and an unhappy tech is a dangerous tech. It's scary when companies don't want people with to much skill.
The preceding post was not a Slashvertisement.
I agree with this completely. Every IT manager / CIO should have to read Peopleware.
In no other job are you asked to do the equivalent of tracing through 10000 lines of code to track a potential threading problem while working around people answering phones and having loud conversations about TV shows. Meanwhile your manager keeps asking you what a thread is and why it takes so long to find one because he needs to present a 10 word summary of the problem to his manager and hasn't programmed since 1973..
After 4 days when you finally find the problem and explain that it's a three line code fix, you're not given the slightest bit of credit because as we know, IT workers are a commodity and anyone could have solved that problem. Even the guy who created the threading issue by putting a static PreparedStatement in a servlet to make it 'efficient' could have fixed it. It said on his resume that he knew JDBC..
Good IT workers are rare. Our office is filled with people with 10 years of experience in XML who try to emulate transactions by writing delete statements for inserted rows because they haven't heard of distributed transactions. They code everything according to 'design patterns' making it a nightmare to debug. Eventually you're the one who gets stuck with the problem of figuring out why credit card transactions are being credited to the wrong customers. Management doesn't see the difference between you and Mr. Design Patterns, except that he gets all his projects in on time and you're always late. The time you spend cleaning that dung heap of design patterns gets charged to 'General Maintenance' and is invisible...
If IT people built cars, they would randomly start reversing on the highway and about every 10 minutes the steering wheel would get stuck while the car tried to figure out what it should do next. Sometimes it would just explode without any reason. Upper management would send a retail manager to put together a team to fix the problem.
Coding is just as much of a thinking job as research.. sometimes it's easy because the problem is simple and well known (power cable not plugged in). Sometimes it's esoteric, and then you really need good IT people with a breadth of knowledge and excellent problem solving skills - you know, the ones you drove away with idiotic management and commoditisation.
Guido von Guido -- Obviously, if you compare a well-run creative solution to a poorly-run noncreative solution, the latter will not seem as good. But all else being equal, the creative solution, by virtue of a change taking place, will be more risky. Financial institutions would rather stick with COBOL systems built in the 1980s than take on risk. In fact, they DO stick w/ COBOL systems built in the 1980s, rather than using the latest spiffy Java-based reporting solution.
Did you go to Business School?
Forget thrust, drag, lift and weight. Airplanes fly because of money.
I'm NOT saying be careless. But there's that quote "chance favors the prepared mind" and having more than one way to solve a problem ready and tested is being prepared.
The problem is with the schools..
Kids go to school, get good grades and think they are smart.. when they are not.
from the original article.. appears to be an inhouse tech, upset that they are required to do their job and do it well. and the only reason to be upset is they cannot do it well.
The learning and grading 'curve' implemented in US schools is churning out incomplete individuals and throwing them into a field. it's all about money in the schools. when everyone is failing.. lower the grading curve.. do it over and over enough and soon you are churning out idiots with degrees.. you can see this in many different fields let along IT.
If your a good System administrator.. you will NOT be putting out fire after fire..
because you will have things in order..
reasoned and understood, there are scenarios where an overhead makes the final descisions, and wrong ones at that.. trickling down to fires popping up.
but this is not a problem when the IT personel are schooled in speach and business as well as Geek knowledge.. because they will then possess the faculties to convince peers and higher ups, that they should be the man/woman for 'the job'. 'the job' being the one that includes making descisions.
when I say schooled in speech and business.. you can show your uppers, exact reasoning for your madness in your 'creativity' of choices for change, charts/graphs/statistics and also real people as witness testimonials of your idea, and that it works are needed to be expressed to the descision makers.. if your idea is rock solid and backed by "good education" and embodied in a sound minded (not winey) IT individual.. the job door will open up.. so will responsibility..
If you can't take the heat.. get out of the kitchen.. try your hand at something else.. and let the company hire a true professional.. I'm not trying to step on toes or hurt anyones feelings.. but truth is truth.. there are rock solid methods.. and that's what companies want..
if you can't give that.. they will look for someone else who will.
if you hate fighting the fires that spring up.. your not doing your job right in the first place, or there would be no fires..
savvy?
because now the bosses will make sure that she *is* replaceable, and once she is she will be let go and somebody at her original (lower) salary will be hired: you have to remember that for managers/execs everybody is pretty much a cog, and if you can get a cheaper cog somewhere else you will be let go.
The right way to approach this situation is to tell the new job that you will start a month late, to tell the old job that you realize they are in a bind, and that they can have your services on contract for a month to transfer information for $200/hr, $400/hr for overtime: this way she'll make a pile of money *and* she'll have a job to go to afterwards where she'll be sure she won't be replaced asap.
Business relationships are not personal relationships, management treats individual workers like expendable resources, why shouldn't you behave the same way?
-- the cake is a lie
From a business angle, this is the typical attitude and approach. The problem is that it isolates and compartmentalizes the entire effort (and its costs). Business types like this because it makes projects predictable. They know how much it costs to reinvent the wheel. So the programmers plow through the project, build something that creaks and barely holds itself together, and performs horribly. But it passes its tests, and additional hardware can be purchased to deal with the performance problems, so the company moves forward and onward.
And then when the application has problems, Someone Else has to fight the fires and we end up exactly where this article was suggesting.
You can't manage IT like other organizations. IT is all about creativity and collaboration. When you manage IT like an assembly line, you never get better at what you do. You just churn out widgets. Who cares that Bob's team built a widget already for that other project? They steamrolled through it and produced something hard to maintain and understand, and since we too are due date-driven, it's faster for us to reinvent it than retrofit their solution.
It is possible, however, that IT managers have actually considered all of this, and have determined that buzzwords like "reusability" and "componentization" aren't worth implementing, because it's cheaper to churn out shitty work that just barely meets business requirements than it is to produce good work, because the good work saves us less in the long run than just building something new from scratch and paying more to support it.
At an enterprise level, programmers don't come up with features. Programmers code the features that the business/requirements types come up with. For many types of projects, programmers are not involved in the requirements phase of a project at all, and only if they're lucky, they might be brought in during the design phase. Commodity programmers are normally handed technical requirements, sometimes even an API, and told to code it. Programmers can't just add random features to an application without fully engaging the bureaucracy of the project.
Even when you consider software development companies instead of general IT organizations in non-software companies, the really interesting thought and planning is done by senior architects, not the bulk of the programmer work force.
This, too, is a problem, in my opinion.