Well, I was not describing my personal situation but a common situation faced by developers. I am fortunate enough to have a CEO who gets it and is willing to pay for architecture-level changes.
I teach, have an open source project that I've been nurturing for years and have published books. I have been doing this for 14 years. They don't call me the code monkey--they call me the architect. You may look on it as being a wage slave but I am already salaried so time is not really ever the issue. I do all this to save myself future time. You have a lot of bitterness. Not me.
We are pros and we keep our jobs based on the overall performance of our jobs. That small amount of extra time I give away stops me from spending many late nights other days trying to figure out a way to shoe-horn in my hack on top of 50 previous hacks. I am being strategic--not just reactive--which is the silent alternative. I am preventing problems. If you think the alternative way saves your time, you're just naive.
I started off fixing everything I saw and made exactly the mistakes you describe.
Then I reverted to holding my nose and adding my hack.
Now, I have found that I am experienced enough that I identify the hacked-up code and start to compile a list of all the use cases that hit it. I don't just dive on that hand grenade, I put on the bomb-suit and make a plan to take it out. Yes, you always miss some obscure use case that gets you a tiny bit--but I promise you it's a much better place to be and after those few missed use cases are nailed, you are really in a happy place.
No, you don't understand at all. The old system had all kinds of abominations such as database-access code mingled inside of JSPs and inline styles. So, I rewrote their apps with clean separation into tiers with proper style sheets and security and proper service/Dao layers. I actually got them to use a source control system rather than storing code in developer's unix home directories. I insisted on primary keys for DB tables and all kinds of no brainers like that. I resisted the urge to use Hibernate because I knew the existing staff could not support that. So, you underestimated the scope of what I fixed. What I left behind will be much easier to maintain. Separating the view code from the DB access code alone made it infinitely easier to support. Using PreparedStatements instead of Statements made their lives so much easier and removed a whole class of defects from occurring.
The difference between dumb and smart is not measured in percentages--but in orders of magnitude.
Welcome to the real world. In every profession the true professional spends much more time than they bill to make sure they do a quality job. While I agree it's counterproductive because it changes expectations, this is a cost of doing business. I'm sure you spend plenty of time on your couch watching TV when I and others like me are writing code, learning new technologies and in general kicking your ass. I have not had to worry about being replaced by an offshore resource for the last decade because I have invested heavily in my own brain. Producing a brilliant design is worth the time I spend on it. I have no respect for lazy fools who expect to be paid for every little thing. You invest in yourself and you reap the rewards year after year. I'm sure your "family time" is spent watching TV or drinking beer. If you are lazy--admit it.
Sir, I have spent many years building brand-new green field systems. Then again, every company has their legacy systems and they expect every architect to be willing to dig into those. I have had great success in my career by being willing to work on any project--green field new development and on existing systems. Primadonnas like you are the kind that give software developers a bad name in the eyes of the business side. I made $200,000 a year in NYC just because I was willing to go into companies in a world of pain and rewrite their systems from scratch. They always had drones who made less than half of what I did, but I took their technical debt off their laps and cheerfully solved all their problems. I sense that you are a pain in the ass to work with and you would cause your employers to roll their eyes. I'm glad you don't work for me now.
I will agree that many times what I called "Techical Debt" is just bad coding that was there when you got there.
But another kind is caused by changing requirements. You design a system to meet the needs of the requirements when it is first written. But, as we know, over time the uses for a system can change. A system that was initially intended to support 100 users can grow to support 10,000 users. When that happens, your original design may not be up to the challenge and a redesign becomes necessary. You can retort that you should have built your 100-user system to support 10,000 users but that sort of overbuilding is another kind of mistake.
In other cases, an old system could have been built with EJBs for the solitary purpose of gaining the transaction support. After that system has been in place for a few years, it may make sense to rebuild it using a technology that emerged later such as Spring or Hibernate. In that case, the old system is technically fine (as much as an EJB can be) but a lighter weight and smarter technology such as Spring is a better idea. In that example, I would consider the original system to be a "technical debt" only in light of a newly emerged technology.
Take another example: a system that was originally built using simple declarative or programmatic transactions. Then, as the needs of the system change, it becomes necessary to support higher speed transactions. In that rare circumstance, the strategy of using rigid ACID transactions may change and the architect may realize that a high-performance design needs to be implemented.
Paradoxically, a high-performance design might remove the direct implementation of rigid ACID and instead use something called a "Compensation system". That's the way super-high-performance systems are built. They don't try to implement a two-phase commit and instead build a "Compensation system" that tracks the updates that have been performed and--if some issue arises--undoes those updates in reverse order. That keeps the intent of ACID without actually using official transactions.
That is an example of a technical debt. The original system may have had no problems but outside events called for a major redesign. To my original point, no CEO would pay for that massive change. This is an example of the sort of "Technical Debt" that does not mask any incompetence--just changing use cases.
Not only is the modern corporation and its CEO unwilling to pay for R&D, they are unwilling to pay for the Technical Debt of their existing systems.
Software developers who work in production support know they will only be able to fix individual defects that have been targeted by the business customers. So, any production system becomes a series of code compromises. Developers fix individual issues and never do a broad refactoring of the code base. So, when a developer comes to a page, sees it's a collection of compromise/hacks, there is no stomach from the business to taking the time to refactor the page. So, instead, the developer holds his nose and adds another hack. Horrible.
So, developers do the refactoring on the sly. If they are really honorable, they come in on their own time and implement architectural improvements on their own dime.
No one in business understands it idea of Technical Debt and the value in future bugs prevented of paying that debt off.
This sort of non-argument just labels you an idiot--even more than your cowardly refusal to stand behind your comments. Do you think this does anything more than degrade you as a human being? It certainly does not have any effect on me other than making me laugh at you as a worthless waste of oxygen.
Taxes are a blunt instrument that are regressive. I would prefer something that more closely attacks the problem. And as I have said, you face no privacy invasion if you ride your bike. People do not realize the number of miles you can conveniently cover on a bike.
You can live anywhere you want. That's what it means to live in the USA. Now, if you want someone to give you a job, then your choices are diminished.
Make your own business and you're home free. Can't do that? Then stop whining. Furthermore, it is only the most restrictive, covenant-bound suburb that limits the color you can paint your house. But anybody who chooses to live in one of those places has already chosen to enter hell and gets what they deserve.
Dude, you are MISSING the point. Don't drive! Ride a bike! Walk! Take public transit and you are anonymous! Why must you drive a 2,000lb hunk of metal everywhere?
I'm sorry if you have a fat ass.That's not my fault. And I don't look on fatness as a sign of intelligence. Sorry to break the news to you, Jumbo.
You are going in the right direction but the Dutch model could achieve the same goal since they would know what kind of car you had.
Still, the goal is to discourage and eventually eliminate the idea that it's normal to drive a 2,000lb hunk of metal around all day. That idea is only favored by Exxon-Mobil and Shell. They want you to blow gas and don't care about the consequences. The Dutch model discourages cars altogether. And if you're not driving a car, there are no privacy implications for you.
Whiner. Each of us is an adult who can work to make the cities better. If they are allegedly rancid, it's because we have focused our money and attention on building roads out to the stupid suburbs. Hang your strip malls.
If you are worried about the privacy implications--ride a bike! Nobody will track your bike. The point is to discourage driving. You should be able to walk to get your food. Ever heard of the local movement? Even in New York City, there were farmers who grew vegetables in Brooklyn or Queens and they sold them in Farmer's Markets. If New York City can do it, then there is no other place that can't.
No, we have chosen to spread out. Nobody forces you to live in the suburbs. Nobody forces you to have a lawn. Why do you need so much space? I used to live in New York City. I rode the subway every day and it was glorious not having to drive. Now I live in a Midwestern city. When I moved here for an awesome new job, I first went to the office. Then I looked for the closest acceptable apartment complex and rented a place. I am 5 minutes from work. You could do the same. If you say you "need" to have a lawn, then suffer and like it.
There is NOTHING except the resistance of the car-centric culture from creating public transit all across America.
Slashdot Mirror
Well done, sir.
You have a point. You full well have the right to waste this one life you get any way you see fit.
Well, I was not describing my personal situation but a common situation faced by developers. I am fortunate enough to have a CEO who gets it and is willing to pay for architecture-level changes.
I teach, have an open source project that I've been nurturing for years and have published books. I have been doing this for 14 years. They don't call me the code monkey--they call me the architect. You may look on it as being a wage slave but I am already salaried so time is not really ever the issue. I do all this to save myself future time. You have a lot of bitterness. Not me.
Not true. Doing what I described has gotten me made the architect.
We are pros and we keep our jobs based on the overall performance of our jobs. That small amount of extra time I give away stops me from spending many late nights other days trying to figure out a way to shoe-horn in my hack on top of 50 previous hacks. I am being strategic--not just reactive--which is the silent alternative. I am preventing problems. If you think the alternative way saves your time, you're just naive.
I started off fixing everything I saw and made exactly the mistakes you describe.
Then I reverted to holding my nose and adding my hack.
Now, I have found that I am experienced enough that I identify the hacked-up code and start to compile a list of all the use cases that hit it. I don't just dive on that hand grenade, I put on the bomb-suit and make a plan to take it out. Yes, you always miss some obscure use case that gets you a tiny bit--but I promise you it's a much better place to be and after those few missed use cases are nailed, you are really in a happy place.
I take pride in my work.
[No, my idea of family time is playing with my son. I stopped watching TV in 8th grade. I drink about 2 cans a beer a year.]
No, you don't understand at all. The old system had all kinds of abominations such as database-access code mingled inside of JSPs and inline styles. So, I rewrote their apps with clean separation into tiers with proper style sheets and security and proper service/Dao layers. I actually got them to use a source control system rather than storing code in developer's unix home directories. I insisted on primary keys for DB tables and all kinds of no brainers like that. I resisted the urge to use Hibernate because I knew the existing staff could not support that. So, you underestimated the scope of what I fixed. What I left behind will be much easier to maintain. Separating the view code from the DB access code alone made it infinitely easier to support. Using PreparedStatements instead of Statements made their lives so much easier and removed a whole class of defects from occurring.
The difference between dumb and smart is not measured in percentages--but in orders of magnitude.
Welcome to the real world. In every profession the true professional spends much more time than they bill to make sure they do a quality job. While I agree it's counterproductive because it changes expectations, this is a cost of doing business. I'm sure you spend plenty of time on your couch watching TV when I and others like me are writing code, learning new technologies and in general kicking your ass. I have not had to worry about being replaced by an offshore resource for the last decade because I have invested heavily in my own brain. Producing a brilliant design is worth the time I spend on it. I have no respect for lazy fools who expect to be paid for every little thing. You invest in yourself and you reap the rewards year after year. I'm sure your "family time" is spent watching TV or drinking beer. If you are lazy--admit it.
Sir, I have spent many years building brand-new green field systems. Then again, every company has their legacy systems and they expect every architect to be willing to dig into those. I have had great success in my career by being willing to work on any project--green field new development and on existing systems. Primadonnas like you are the kind that give software developers a bad name in the eyes of the business side. I made $200,000 a year in NYC just because I was willing to go into companies in a world of pain and rewrite their systems from scratch. They always had drones who made less than half of what I did, but I took their technical debt off their laps and cheerfully solved all their problems. I sense that you are a pain in the ass to work with and you would cause your employers to roll their eyes. I'm glad you don't work for me now.
I will agree that many times what I called "Techical Debt" is just bad coding that was there when you got there.
But another kind is caused by changing requirements. You design a system to meet the needs of the requirements when it is first written. But, as we know, over time the uses for a system can change. A system that was initially intended to support 100 users can grow to support 10,000 users. When that happens, your original design may not be up to the challenge and a redesign becomes necessary. You can retort that you should have built your 100-user system to support 10,000 users but that sort of overbuilding is another kind of mistake.
In other cases, an old system could have been built with EJBs for the solitary purpose of gaining the transaction support. After that system has been in place for a few years, it may make sense to rebuild it using a technology that emerged later such as Spring or Hibernate. In that case, the old system is technically fine (as much as an EJB can be) but a lighter weight and smarter technology such as Spring is a better idea. In that example, I would consider the original system to be a "technical debt" only in light of a newly emerged technology.
Take another example: a system that was originally built using simple declarative or programmatic transactions. Then, as the needs of the system change, it becomes necessary to support higher speed transactions. In that rare circumstance, the strategy of using rigid ACID transactions may change and the architect may realize that a high-performance design needs to be implemented.
Paradoxically, a high-performance design might remove the direct implementation of rigid ACID and instead use something called a "Compensation system". That's the way super-high-performance systems are built. They don't try to implement a two-phase commit and instead build a "Compensation system" that tracks the updates that have been performed and--if some issue arises--undoes those updates in reverse order. That keeps the intent of ACID without actually using official transactions.
That is an example of a technical debt. The original system may have had no problems but outside events called for a major redesign. To my original point, no CEO would pay for that massive change. This is an example of the sort of "Technical Debt" that does not mask any incompetence--just changing use cases.
Not only is the modern corporation and its CEO unwilling to pay for R&D, they are unwilling to pay for the Technical Debt of their existing systems.
Software developers who work in production support know they will only be able to fix individual defects that have been targeted by the business customers. So, any production system becomes a series of code compromises. Developers fix individual issues and never do a broad refactoring of the code base. So, when a developer comes to a page, sees it's a collection of compromise/hacks, there is no stomach from the business to taking the time to refactor the page. So, instead, the developer holds his nose and adds another hack. Horrible.
So, developers do the refactoring on the sly. If they are really honorable, they come in on their own time and implement architectural improvements on their own dime.
No one in business understands it idea of Technical Debt and the value in future bugs prevented of paying that debt off.
[Native of Nebraska. Currently call Indiana home. So, you are certainly a cretin.]
You're probably already carrying your own GPS unit in your pocket now--your cell phone.
This sort of non-argument just labels you an idiot--even more than your cowardly refusal to stand behind your comments. Do you think this does anything more than degrade you as a human being? It certainly does not have any effect on me other than making me laugh at you as a worthless waste of oxygen.
Taxes are a blunt instrument that are regressive. I would prefer something that more closely attacks the problem. And as I have said, you face no privacy invasion if you ride your bike. People do not realize the number of miles you can conveniently cover on a bike.
You can live anywhere you want. That's what it means to live in the USA. Now, if you want someone to give you a job, then your choices are diminished.
Make your own business and you're home free. Can't do that? Then stop whining. Furthermore, it is only the most restrictive, covenant-bound suburb that limits the color you can paint your house. But anybody who chooses to live in one of those places has already chosen to enter hell and gets what they deserve.
Yes it does. And the same forces who were encouraged to build in the suburbs will instead build in the city. End of problem.
Dude, you are MISSING the point. Don't drive! Ride a bike! Walk! Take public transit and you are anonymous! Why must you drive a 2,000lb hunk of metal everywhere?
I'm sorry if you have a fat ass.That's not my fault. And I don't look on fatness as a sign of intelligence. Sorry to break the news to you, Jumbo.
You are going in the right direction but the Dutch model could achieve the same goal since they would know what kind of car you had.
Still, the goal is to discourage and eventually eliminate the idea that it's normal to drive a 2,000lb hunk of metal around all day. That idea is only favored by Exxon-Mobil and Shell. They want you to blow gas and don't care about the consequences. The Dutch model discourages cars altogether. And if you're not driving a car, there are no privacy implications for you.
Trolling? The guy who wrote 'Fuck you' was a troll. Someone like me who has come back and come back to defend my initial post is no troll.
Whiner. Each of us is an adult who can work to make the cities better. If they are allegedly rancid, it's because we have focused our money and attention on building roads out to the stupid suburbs. Hang your strip malls.
If you are worried about the privacy implications--ride a bike! Nobody will track your bike. The point is to discourage driving. You should be able to walk to get your food. Ever heard of the local movement? Even in New York City, there were farmers who grew vegetables in Brooklyn or Queens and they sold them in Farmer's Markets. If New York City can do it, then there is no other place that can't.
No, we have chosen to spread out. Nobody forces you to live in the suburbs. Nobody forces you to have a lawn. Why do you need so much space? I used to live in New York City. I rode the subway every day and it was glorious not having to drive. Now I live in a Midwestern city. When I moved here for an awesome new job, I first went to the office. Then I looked for the closest acceptable apartment complex and rented a place. I am 5 minutes from work. You could do the same. If you say you "need" to have a lawn, then suffer and like it.
There is NOTHING except the resistance of the car-centric culture from creating public transit all across America.