The “Real World” is depressing me(lazarski.me)
lazarski.me
The “Real World” is depressing me
http://lazarski.me/blog/real-world-depressing/
55 comments
Agreed. I had this problem a lot when I was starting out. I could not believe why they would use such outdated software. One company was even still using a COBOL program and this was in 2010. Then I realized that the people who use the program are not engineers, they are people just trying to do their job. Software just has to work and it does not matter what language or protocol it uses. This is often hard to swallow but the fact is companies make money off software doing its job, and sometimes its job does not require "secure" or "fast".
There's nothing inherently wrong with software being old and outdated, that may just mean the software was designed well enough to be long-lasting.
However, the problems come when you're working with software that's decades old, has no master feature list, sparse documentation and no unit test coverage for countless feature enhancements and business rules that were tacked on over the years, so no one understands everything that it does and no one can touch the code without breaking something unpredictably, plus it's monolithic and not modular or portable at all, so it's really hard to migrate any part of its functionality. And it's in a language no one learns anymore, so it's really hard to hire developers. Meanwhile your business has become so dependent on it that you can't continue to make money unless the program continues doing its job. So the software will only continue to get older and more outdated, because it's irreplaceable for all the wrong reasons.
Sure, it's fine to still be on a COBOL system, but in reality I bet that most companies that are still on COBOL would migrate to more modern and maintainable systems if they could. But they can't, they're locked in by the amount of technical debt they've accumulated.
However, the problems come when you're working with software that's decades old, has no master feature list, sparse documentation and no unit test coverage for countless feature enhancements and business rules that were tacked on over the years, so no one understands everything that it does and no one can touch the code without breaking something unpredictably, plus it's monolithic and not modular or portable at all, so it's really hard to migrate any part of its functionality. And it's in a language no one learns anymore, so it's really hard to hire developers. Meanwhile your business has become so dependent on it that you can't continue to make money unless the program continues doing its job. So the software will only continue to get older and more outdated, because it's irreplaceable for all the wrong reasons.
Sure, it's fine to still be on a COBOL system, but in reality I bet that most companies that are still on COBOL would migrate to more modern and maintainable systems if they could. But they can't, they're locked in by the amount of technical debt they've accumulated.
We have tons of actively used and maintained COBOL systems (including new features/requirements). The cost to rewrite and test these systems would be extremely high, since there is a tremendous amount of business logic embedded within them. In most cases, it is cheaper and makes more sense to continue to supporting the existing applications.
For me, the worst part is two years in the industry doing small part time gigs and the author thinks he is smarter than most of the other people there. And after one year of 'debugging, refactoring and getting the build to work' he quit cause he didn't know how he could fix the project.
Seriously? And he has the guts to say Enterprise is broken with his so many years of experience.
What is with this trend where people with 1-2 years of experience think they know more than 100s of people with more years experience than they have been alive shouting this bullcrap? And I have nothing against youth, I started my career at 18 after dropping out of school, but I had the good sense of not being an arrogant know it all that wanted to rewrite complete systems on my first real job.
Seriously? And he has the guts to say Enterprise is broken with his so many years of experience.
What is with this trend where people with 1-2 years of experience think they know more than 100s of people with more years experience than they have been alive shouting this bullcrap? And I have nothing against youth, I started my career at 18 after dropping out of school, but I had the good sense of not being an arrogant know it all that wanted to rewrite complete systems on my first real job.
Having pretty software and good code makes my job easier. It's less about the company being successful and more about my work day not being compromised by anger.
hey the author here.
It depends on what you mean by large.
Not world wide large but large like 500 people worked there. I was just a frontend jquery guy how was doing some fancy frontend stuff but i head a look into the company.
They failed not because of old code. What is bad code choices ?
"we as software developers are simply there to enable people to do their jobs better." Exactly!
"it's to make a business successful." Right. For example in a company which was a eCommerce Company. They wrote the eCommerce Software them self and it worked for 6 years but they got bigger and bigger and the manager didn't care to make the software better. One day the main developer quit the job and nobody now would know how to change that or to do that. is this still a good Bad/inelegant/old software ?
Not world wide large but large like 500 people worked there. I was just a frontend jquery guy how was doing some fancy frontend stuff but i head a look into the company.
They failed not because of old code. What is bad code choices ?
"we as software developers are simply there to enable people to do their jobs better." Exactly!
"it's to make a business successful." Right. For example in a company which was a eCommerce Company. They wrote the eCommerce Software them self and it worked for 6 years but they got bigger and bigger and the manager didn't care to make the software better. One day the main developer quit the job and nobody now would know how to change that or to do that. is this still a good Bad/inelegant/old software ?
That context of size is important. To some people, 500 is a large company. Indeed, in many respects, 500 really is a large company. Only ~0.3% of US companies have more than 500 people [1]. But HP has 317,000 employees. So depending on who you are talking to, "large" suggests different things.
[1]: http://www.census.gov/econ/smallbus.html
[1]: http://www.census.gov/econ/smallbus.html
To me that's not a software problem, that's a management problem. That organization did not pass the hit-by-a-bus test, it's just that in this case the bus was the main dev walking away.
That's a planning / organization problem, not an IT / software one.
That's a planning / organization problem, not an IT / software one.
In companies often developer do organizing too.
Or you have influence on the management
I'm assuming your anecdotes (the 500 person company and the eCommerce company) are two different companies? Because if a 500 person company folded when they lost a single employee then there's a whole lot more messed up than quality of code.
Yes should point that out more clear!
the 500 person company had more then just technical problems.
the 500 person company had more then just technical problems.
No, my job is to work and your job is to pay me. If your business is successful or not, is none of my problem. Fuck you, pay me. I write your stupid shit enterprise cruft all day and cash your worthless benefits. You want me to create and generate new value? Fuck you, pay me. Nobody cares about your groundbreaking technology that is the foundation of thousands of other bullshit businesses selling nothing but hustle. Put the cash in my hand so I can get the fuck out of here.
Wow, just... wow. There are companies in this world that you can get behind, where you can "generate value", and where your involvement actually improves your life instead of shitting all over it. I'm sorry you think the world is divided between soulless snake-oil corporations and mercenary employees, both of whom are out to totally fuck the other over. That's a dark world to have to live in.
It's not dark (more appropriately, it's not false), it's just overstatement. Most employees just want a paycheck, and most employers want to maximize profit at whatever cost.
We all live in the world in which this happens. Not all of us, thankfully, are employed in that part of the world; that does not mean, though, that it does not exist. I'm glad you're not part of it; I'm not, either, but only because I left and made my own way. It wasn't easy, and still isn't, but it was and is worth it.
It's easy to dismiss doom and gloom because it's not everywhere. But the GP's experience is perfectly real.
We all live in the world in which this happens. Not all of us, thankfully, are employed in that part of the world; that does not mean, though, that it does not exist. I'm glad you're not part of it; I'm not, either, but only because I left and made my own way. It wasn't easy, and still isn't, but it was and is worth it.
It's easy to dismiss doom and gloom because it's not everywhere. But the GP's experience is perfectly real.
Doing good work for the money does not make you a mercenary (in whatever bad sense you're implying here.) It makes you like 95% of the workers in the world. Are people who work at McDonald's fucking them over if they don't give a shit about corporate's goals?
"Fuck you, pay me" is the beginning of wisdom in this industry.
Corporates are not human so I'm not sure what your basing your opinion on.
A bit of context for "Fuck you, pay me": http://www.youtube.com/watch?v=6h3RJhoqgK8
Wow, what's with the rage? Find a job with a company you like, and get some proper job gratification and self respect, please.
I've been working in that "real world" for a long time and I've seen plenty of what the author is describing and relate to the frustration.
However, there are a couple of things that I'd ask someone new to that world to consider:
* It's trivial to point out all the ways some existing system is broken and how much better it could be given a imaginary greenfield to recreate it.
It's legitimately hard to figure out how to remediate or replace that system while keeping the business moving by scheduling downtime, training users, managing expectations, working within a budget, working within the abilities of your staff or finding new staff.
I've seen more than a few otherwise smart (typically young) people poison themselves and everyone around them by being impatient, idealistic and simply ignorant about everything beyond their own desktop.
* Doing the hard things, taking the broken stuff and making it shine builds credibility and trust. It's rare that you can come in the door and start reinventing a place, but given a solid track record - you absolutely can or at least be given the autonomy to work on more satisfying things.
* I don't have start-up experience to make a direct comparison, but I do know that the typical rates I've seen for equivalent roles in a few start-ups and even some of the prestigious SV BigCos are low to terrible relative to what's available to competent people with a track record in "enterprise".
* If you take it seriously, I think there's actually something a lot of satisfaction to be had in an enterprise. You're not racking up a million users, but you are getting a shot to change the lives of thousands if not tens of thousands of people who depend on your software and systems for their livelihood and interact with it for 8 hours of every day.
However, there are a couple of things that I'd ask someone new to that world to consider:
* It's trivial to point out all the ways some existing system is broken and how much better it could be given a imaginary greenfield to recreate it.
It's legitimately hard to figure out how to remediate or replace that system while keeping the business moving by scheduling downtime, training users, managing expectations, working within a budget, working within the abilities of your staff or finding new staff.
I've seen more than a few otherwise smart (typically young) people poison themselves and everyone around them by being impatient, idealistic and simply ignorant about everything beyond their own desktop.
* Doing the hard things, taking the broken stuff and making it shine builds credibility and trust. It's rare that you can come in the door and start reinventing a place, but given a solid track record - you absolutely can or at least be given the autonomy to work on more satisfying things.
* I don't have start-up experience to make a direct comparison, but I do know that the typical rates I've seen for equivalent roles in a few start-ups and even some of the prestigious SV BigCos are low to terrible relative to what's available to competent people with a track record in "enterprise".
* If you take it seriously, I think there's actually something a lot of satisfaction to be had in an enterprise. You're not racking up a million users, but you are getting a shot to change the lives of thousands if not tens of thousands of people who depend on your software and systems for their livelihood and interact with it for 8 hours of every day.
"I've been working in that "real world" for a long time and I've seen plenty of what the author is describing and relate to the frustration."
Thank you.
"However, there are a couple of things that I'd ask someone new to that world to consider: * It's trivial to point out all the ways some existing system is broken and how much better it could be given a imaginary greenfield to recreate it. It's legitimately hard to figure out how to remediate or replace that system while keeping the business moving by scheduling downtime, training users, managing expectations, working within a budget, working within the abilities of your staff or finding new staff. I've seen more than a few otherwise smart (typically young) people poison themselves and everyone around them by being impatient, idealistic and simply ignorant about everything beyond their own desktop."
Maybe I'm one of the typical young people. I don't know. But when I come to a Company and see thing that can be improved why not improve them?
"* Doing the hard things, taking the broken stuff and making it shine builds credibility and trust. It's rare that you can come in the door and start reinventing a place, but given a solid track record - you absolutely can or at least be given the autonomy to work on more satisfying things."
It should be more like a transition. Take one peace make it shiny and then take the next.
"* If you take it seriously, I think there's actually something a lot of satisfaction to be had in an enterprise. You're not racking up a million users, but you are getting a shot to change the lives of thousands if not tens of thousands of people who depend on your software and systems for their livelihood and interact with it for 8 hours of every day."
At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think).
Thank you.
"However, there are a couple of things that I'd ask someone new to that world to consider: * It's trivial to point out all the ways some existing system is broken and how much better it could be given a imaginary greenfield to recreate it. It's legitimately hard to figure out how to remediate or replace that system while keeping the business moving by scheduling downtime, training users, managing expectations, working within a budget, working within the abilities of your staff or finding new staff. I've seen more than a few otherwise smart (typically young) people poison themselves and everyone around them by being impatient, idealistic and simply ignorant about everything beyond their own desktop."
Maybe I'm one of the typical young people. I don't know. But when I come to a Company and see thing that can be improved why not improve them?
"* Doing the hard things, taking the broken stuff and making it shine builds credibility and trust. It's rare that you can come in the door and start reinventing a place, but given a solid track record - you absolutely can or at least be given the autonomy to work on more satisfying things."
It should be more like a transition. Take one peace make it shiny and then take the next.
"* If you take it seriously, I think there's actually something a lot of satisfaction to be had in an enterprise. You're not racking up a million users, but you are getting a shot to change the lives of thousands if not tens of thousands of people who depend on your software and systems for their livelihood and interact with it for 8 hours of every day."
At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think).
>"Maybe I'm one of the typical young people. I don't know. But when I come to a Company and see thing that can be improved why not improve them?"
There's absolutely nothing wrong with wanting to improve things, but there's plenty that can go wrong and hurt everyone involved depending on how you go about it.
>"It should be more like a transition. Take one peace make it shiny and then take the next."
Sure, so long as whatever is working continues to work to whatever extent that work implies along with all the connected concerns including, but not limited to:
* Maintaining equivalent expertise in the development, administration, operations and support teams.
* Discovering and accommodating connected systems, whether they themselves are documented or not.
* Complete documentation of the solution.
* Setting and meeting realistic schedules.
* User training.
* Testing.
Most of those things are not nearly as sexy as rewriting old code in a fast new language or implementing some kind of bleeding edge system, but they are absolutely necessary.
It's not just write, compile, launch and move onto the next.
I don't want to accuse here, but it's hard to imagine full cycles of those sorts of things happening for a project of reasonable size, relating to currently broken systems in multiple jobs within two years.
>"At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think)."
I'm not sure what you're saying here.
There's absolutely nothing wrong with wanting to improve things, but there's plenty that can go wrong and hurt everyone involved depending on how you go about it.
>"It should be more like a transition. Take one peace make it shiny and then take the next."
Sure, so long as whatever is working continues to work to whatever extent that work implies along with all the connected concerns including, but not limited to:
* Maintaining equivalent expertise in the development, administration, operations and support teams.
* Discovering and accommodating connected systems, whether they themselves are documented or not.
* Complete documentation of the solution.
* Setting and meeting realistic schedules.
* User training.
* Testing.
Most of those things are not nearly as sexy as rewriting old code in a fast new language or implementing some kind of bleeding edge system, but they are absolutely necessary.
It's not just write, compile, launch and move onto the next.
I don't want to accuse here, but it's hard to imagine full cycles of those sorts of things happening for a project of reasonable size, relating to currently broken systems in multiple jobs within two years.
>"At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think)."
I'm not sure what you're saying here.
"Maybe I'm one of the typical young people. I don't know. But when I come to a Company and see thing that can be improved why not improve them?"
Maybe because you don't know jack shit about things are and why they were done like so, and think you are smarter than the other people?
Sorry to be mean but I had to deal with a few people like you, and I ended up being responsible to clean up the fuck ups they did because they had all this shiny ideas on how to improve the code, or how to rewrite components of the software or use a different framework/language because "Java is dead man!" ideas and fucking it up for the business and leaving the team to clean up when they eventually leave because 'company is broken, I tried to fix it, but couldn't because X, but it wasn't my fault'.
Maybe because you don't know jack shit about things are and why they were done like so, and think you are smarter than the other people?
Sorry to be mean but I had to deal with a few people like you, and I ended up being responsible to clean up the fuck ups they did because they had all this shiny ideas on how to improve the code, or how to rewrite components of the software or use a different framework/language because "Java is dead man!" ideas and fucking it up for the business and leaving the team to clean up when they eventually leave because 'company is broken, I tried to fix it, but couldn't because X, but it wasn't my fault'.
>* It's trivial to point out all the ways some existing system is broken and how much better it could be given a imaginary greenfield to recreate it.
Yeah, it is literally the same as saying "I have an idea for a web service/site."
Yeah, it is literally the same as saying "I have an idea for a web service/site."
I don't mean to sound rude here, but welcome to the real world where IT is not the focus of business and is often seen as a cost center and necessary evil. This may not be right, but it's something that has to be dealt with.
I see my role as an IT professional as helping the other members of large organizations to understand what IT can do for them and how it should be used securely and appropriately. It's way, way, way bigger than just enjoying hacking on code or building small networks; it's putting together systems to support business.
After all, for most of the world IT is there to support the business, it's not the businesses' product.
I see my role as an IT professional as helping the other members of large organizations to understand what IT can do for them and how it should be used securely and appropriately. It's way, way, way bigger than just enjoying hacking on code or building small networks; it's putting together systems to support business.
After all, for most of the world IT is there to support the business, it's not the businesses' product.
All valid points. And "Don't think about it" can be valid for things that aren't the main point of concern for your customers. Executives have limited things they can pay attention to. They don't like to change what they don't have to change, so they can focus on what's important.
I agree, I used to get upset because things didn't get done the way I thought should be done. I was worried about a server crashing and not having a budget to get another one, telling people about security and they not following recommendations. I left that company to go to another one a more corporate and bigger company and guess what the same issues, then another company and the same issues. Then I realized that technology is a means to an end. The company's goal is not technology is to make money, to pay investors, to have cash flow, yes technology is important but it is not the primary goal of a company. Code might be ugly or legacy but it pays the bills, now I do great work but don't try to think that everything has to be done a certain way I just adapt, nothing will be perfect.
They could probably start cutting IT costs by learning the difference between their PC tower and their monitor.
Don't be one of those tiresome bitter sysadmins.
I'm not a sysadmin (I'll make no comment on the counts of tiresome or bitter), but it's hard to deny that many people could use the most basic of computer education. I cannot blame you nor anybody else for downvoting those sorts of posts, but can you really blame me for feeling the way I do?
I don't really care to argue over this, so consider that a rhetorical question.
I don't really care to argue over this, so consider that a rhetorical question.
Life's too short to worry about whether somebody can tell one piece of technology from another.
Not if their inability to do so makes one's life shorter.
If people using the wrong terms for electronic office equipment is stressing you out to that extent, it's not healthy, and I would suggest re-considering some of your choices that lead you to this point in life or, if that's not possible, maybe think about getting some help.
That's in all seriousness, btw, it's not worth getting upset about stuff like that.
That's in all seriousness, btw, it's not worth getting upset about stuff like that.
I think that willful ignorance is worth getting upset over. It may not be "healthy", but it's worth it.
And with that, I think I really am done perpetuating this silly discussion.
And with that, I think I really am done perpetuating this silly discussion.
There are some technologies or methodologies that can and should be easily swapped out for better solutions.
But as your career continues, you'll find that you are _always_ learning, and in that process of learning you, too, will do the kind of stupid shit that someday a wiser you will wish you'd done so, so differently. The point is, in time, people and organizations of all sizes build legacy. Yes, even startups. You should actually feel pretty good if you work on something that lives long enough to develop a few warts.
There are two related skills you really have to work to build. The first is the discipline to set time aside to fix the broken things. You'll be surprised how hard that can be. (ESPECIALLY in a startup.)
The second will be tolerance; the ability to accept that, yes, some things are totally wrong in the purest academic sense—and maybe embarrassingly so—but at the same time, they are working and the best customer outcome may be a focus on some other feature.
But as your career continues, you'll find that you are _always_ learning, and in that process of learning you, too, will do the kind of stupid shit that someday a wiser you will wish you'd done so, so differently. The point is, in time, people and organizations of all sizes build legacy. Yes, even startups. You should actually feel pretty good if you work on something that lives long enough to develop a few warts.
There are two related skills you really have to work to build. The first is the discipline to set time aside to fix the broken things. You'll be surprised how hard that can be. (ESPECIALLY in a startup.)
The second will be tolerance; the ability to accept that, yes, some things are totally wrong in the purest academic sense—and maybe embarrassingly so—but at the same time, they are working and the best customer outcome may be a focus on some other feature.
"But as your career continues, you'll find that you are _always_ learning, and in that process of learning you, too, will do the kind of stupid shit that someday a wiser you will wish you'd done so, so differently. The point is, in time, people and organizations of all sizes build legacy. Yes, even startups. You should actually feel pretty good if you work on something that lives long enough to develop a few warts."
I have done bad things. Everybody will.
"There are two related skills you really have to work to build. The first is the discipline to set time aside to fix the broken things. You'll be surprised how hard that can be. (ESPECIALLY in a startup.)
The second will be tolerance; the ability to accept that, yes, some things are totally wrong in the purest academic sense—and maybe embarrassingly so—but at the same time, they are working and the best customer outcome may be a focus on some other feature."
Fair points. Fixing things is always hard. I learned that on the Java Project. And yes as long as they are working I'm on your side. But and that a honest question: What would you do when you see that thing X will break in maybe a year and there is no way to scale it and the manager is ignore that it will break in the near future?
I have done bad things. Everybody will.
"There are two related skills you really have to work to build. The first is the discipline to set time aside to fix the broken things. You'll be surprised how hard that can be. (ESPECIALLY in a startup.)
The second will be tolerance; the ability to accept that, yes, some things are totally wrong in the purest academic sense—and maybe embarrassingly so—but at the same time, they are working and the best customer outcome may be a focus on some other feature."
Fair points. Fixing things is always hard. I learned that on the Java Project. And yes as long as they are working I'm on your side. But and that a honest question: What would you do when you see that thing X will break in maybe a year and there is no way to scale it and the manager is ignore that it will break in the near future?
"But and that a honest question: What would you do when you see that thing X will break in maybe a year and there is no way to scale it and the manager is ignore that it will break in the near future?"
In my opinion the best option is to ensure that your manager understands the forthcoming problem, and even if they choose to ignore it, have a plan for what you'll do when that happens. Sometimes what seems to you like them ignoring the problem is actually acceptance of the risk; a choice to defer action.
If you can be anticipating the problem and be the person ready to get working on a solution when it's finally required you'll usually win heartily. If you fall to an I-told-you-so attitude it won't be very helpful for anyone.
Of course, depending on how management handles it when things do finally fall over you may want to consider looking elsewhere. After all, there's good and bad leaders everywhere...
In my opinion the best option is to ensure that your manager understands the forthcoming problem, and even if they choose to ignore it, have a plan for what you'll do when that happens. Sometimes what seems to you like them ignoring the problem is actually acceptance of the risk; a choice to defer action.
If you can be anticipating the problem and be the person ready to get working on a solution when it's finally required you'll usually win heartily. If you fall to an I-told-you-so attitude it won't be very helpful for anyone.
Of course, depending on how management handles it when things do finally fall over you may want to consider looking elsewhere. After all, there's good and bad leaders everywhere...
Thank you.
Your right
and yes the I-told-you-so attitude is really bad.
Your right
and yes the I-told-you-so attitude is really bad.
>But and that a honest question: What would you do when you see that thing X will break in maybe a year and there is no way to scale it and the manager is ignore that it will break in the near future?
Polish your resume.
Polish your resume.
I disagree that Enterprise is "broken". Enterprise is simply a different set of priorities.
It's important to be able to look at software from a business perspective (where software is simply a tool to accomplish a task) as well as from a developer/maintainer perspective.
For example, I'm currently rewriting a major system that has been in use here for many years. Our estimate right now is the total time for the rewrite will be about 2700 person-hours over the course of about 18 months.
Supporting the existing system takes about 10 to 20 hours per month. The existing system uses deprecated libraries, unsupported 3rd party components, monkey patched to hell, tightly coupled and has many issues. We can't even rebuild the entire thing from source code because we have unlicenseable components!
But, from a business perspective, the current system has run for many years and is likely to continue running. At 10 to 20 hours per months of support, it would take 15 years to add up to the 2700 hours we're spending in less than 2 years on a rewrite. And a rewrite, like any software, won't be zero-support.
In addition to mapping those hours to dollars, they also map to other features in other applications. Every extra hour I spend on this rewrite is a feature or improvement on another application that could have been done, but was deferred.
In the end, from the business perspective, the new application and the current one are basically identical: the serve the same business purpose! So why spend the hours on a rewrite? Why not just continue to support the current system.
So, as a software person, we hate certain badly broken software that we want to bulldozer and start fresh. But from a business perspective, the only concern is value, cost, and ROI.
It's important to be able to look at software from a business perspective (where software is simply a tool to accomplish a task) as well as from a developer/maintainer perspective.
For example, I'm currently rewriting a major system that has been in use here for many years. Our estimate right now is the total time for the rewrite will be about 2700 person-hours over the course of about 18 months.
Supporting the existing system takes about 10 to 20 hours per month. The existing system uses deprecated libraries, unsupported 3rd party components, monkey patched to hell, tightly coupled and has many issues. We can't even rebuild the entire thing from source code because we have unlicenseable components!
But, from a business perspective, the current system has run for many years and is likely to continue running. At 10 to 20 hours per months of support, it would take 15 years to add up to the 2700 hours we're spending in less than 2 years on a rewrite. And a rewrite, like any software, won't be zero-support.
In addition to mapping those hours to dollars, they also map to other features in other applications. Every extra hour I spend on this rewrite is a feature or improvement on another application that could have been done, but was deferred.
In the end, from the business perspective, the new application and the current one are basically identical: the serve the same business purpose! So why spend the hours on a rewrite? Why not just continue to support the current system.
So, as a software person, we hate certain badly broken software that we want to bulldozer and start fresh. But from a business perspective, the only concern is value, cost, and ROI.
It's depressing because it needs to evolve and fix its problems. IT is unregulated, security flaws and bad practice will one day generate so much loss the government might try to impose more quality standards and practice regarding to the law and insurances.
I get your frustration, but if there are problems, you should try to craft new solutions instead of complaining.
I think IT sucks in general because there's a big lack of proper skill in programming skills, available tools, law and how businesses stimulate and reward innovation.
History showed humans overcame many technological challenges, but I think there's always more to do, but it just gets harder and trickier. I think ancient mathematicians and scientist were as frustrated, yet we know now about DNA, we have programming languages, lasers and GPS. In short there will be awesome, crazy solutions in the future one day, but they're so awesome that you don't know about it yet: science fiction and futurology are jokes compared to what real inventions and discoveries end up to be.
I get your frustration, but if there are problems, you should try to craft new solutions instead of complaining.
I think IT sucks in general because there's a big lack of proper skill in programming skills, available tools, law and how businesses stimulate and reward innovation.
History showed humans overcame many technological challenges, but I think there's always more to do, but it just gets harder and trickier. I think ancient mathematicians and scientist were as frustrated, yet we know now about DNA, we have programming languages, lasers and GPS. In short there will be awesome, crazy solutions in the future one day, but they're so awesome that you don't know about it yet: science fiction and futurology are jokes compared to what real inventions and discoveries end up to be.
Site's down: here's a cached copy: http://webcache.googleusercontent.com/search?q=cache:http://...
> Maybe a startup is the best place for me ? I honestly don’t know.
Well, the mediocrity described here is exactly what startups take advantage of, right?
Well, the mediocrity described here is exactly what startups take advantage of, right?
I wouldn't say a startup is the best place for the author, necessarily. Rather, any company where software (or related technology) is a primary line of business, or at least considered so important to the primary line(s) of business as to be deemed (nearly) as valuable.
The fact is most of the "real world" business and enterprise space, as noted by other commenters, just isn't about "developing software." In these places the goal, with respect to software development, is commoditization in order to reduce costs. They don't care if the code is pretty, or even if it actually works all the time. All that matters is that it works well enough to get the job (mostly) done most of the time. Software development is the same as tech support is the same as the CAT5 cable laying guy in these places. It's all "IT", it's all a (very expensive) cost, and it's all something the organization views with a snarl, not a smile. If you want to feel valued as a software worker, don't work at these places.
The fact is most of the "real world" business and enterprise space, as noted by other commenters, just isn't about "developing software." In these places the goal, with respect to software development, is commoditization in order to reduce costs. They don't care if the code is pretty, or even if it actually works all the time. All that matters is that it works well enough to get the job (mostly) done most of the time. Software development is the same as tech support is the same as the CAT5 cable laying guy in these places. It's all "IT", it's all a (very expensive) cost, and it's all something the organization views with a snarl, not a smile. If you want to feel valued as a software worker, don't work at these places.
Welcome to the real world.
(fyi software/it is not the only broken thing in companies)
It's a hard truth to swallow that in the "real world" (read: any business that's not a software company) we as software developers are simply there to enable people to do their jobs better. Our software doesn't exist as an end in itself. We are purely a means. Bad/inelegant/old software can often accomplish a business's goals. It might not be as efficient or pretty as possible, but remember that your job isn't to make pretty software, it's to make a business successful.