3 ms·

The most frustrating thing about being an older programmer is watching organizations make the same mistakes over and over again. Yeah, sure, you might want to

The most frustrating thing about being an older programmer is watching organizations make the same mistakes over and over again. Yeah, sure, you might want to hire an older guy because he has experience with the intangible project stuff. But only if you're planning to listen to him. I feel like Bill Murray's character in Groundhog Day: Me: We need to create our security architecture in the beginning. It's always harder to add when we have a bunch of functionality to work around. Management: But we don't have time. We promised these features by January 1st. Don't worry about security yet - the initial version won't have critical business or customer data. Me: We'll never have time. Once the users get ahold of this we'll be buried under requests for new features and critical bug fixes. Particularly since the only way we have to test it is to have people poke at it in a browser. Management: Adding automated testing would take too much time. Me: ...

ralusek 9y ago
I mean the problem is that you're both probably right. You SHOULD add in tests and security, but you also very likely DON'T have time. Good code can be structured in a way that it's not going to be a nightmare to add in considerations of this nature further down the line, but with this sort of environment of "speed > everything" else, they're not likely to let you implement code well either.
- gozur88 9y ago
  >I mean the problem is that you're both probably right. You SHOULD add in tests and security, but you also very likely DON'T have time. But by doing the things that people can see and skipping the things they can't see you're effectively just lying when you produce a schedule. You don't do automated tests because it's a fun way to kill a Friday afternoon - you do them because they free you up to work on new functionality. So you're not really saving yourself time by not doing them. These kinds of projects are almost always disasters. Invariably the problem is someone in middle management undersold the cost to the people above him. There's not enough time to write the app properly, so they borrow time off the end (with interest) to make it look like things are progressing to the deadline. So you finish the first 90% on schedule and then flail around on the next 90%.
sean2 9y ago
I'm in my early 30s, so frequently called an older programmer and I've heard a lot of, "we don't have time". What I've been waking up to is that projects that estimate realistic budgets and time scales don't get funded. Everyone underbids knowing that the company/customer will continue to fund and extend deadlines for project after sinking so much effort into a buggy prototype, until the realistic estimate is reached and the product actually reflects all the "hidden"/"discovered" requirements (i.e. foreseen but not in the bid) including security, integration and test efforts. What's weird is that everyone, customers included, seems to be in on this.
- gozur88 9y ago
  I think that's true, pretty much. But the downside is they force an inefficient development methodology on you as you try to make the imaginary deadline.
- imhoguy 9y ago
  What you describe is often the scenario of do-everything consulting sweat shop building tailored or customized solution from scratch based on a single customer requirements. Management often lacks business vision and technological path. Front sales and techical people are randomly assigned and switched between ad-hoc projects with varying industry domains and poor communication chanels. I think only debt slave or masochist stay in such places for longer. Age doesn't matter. I would rather look for more focused software product companies with stable teams.
- dennisgorelik 9y ago
  Most of new features are useless, so it does not matter that they are buggy. Only consistently useful features require bug-fixing. It is better to spend more time fixing bugs on few useful features after they implemented and tested by users, than spend time polishing all features (including useless features) up-front.
mmt 9y ago
It's even worse as an old sysadmin, since my Groundhog Day permeates almost every part of the organization.. and I've learned to avert my eyes from the code itself and leave that nightmare to the Old Programmers. Not that any of this is surprising, since the lessons of the semiconductor boom and bust weren't put to adequate use during the dot-com boom and bust, so whatever new lessons we learned then still aren't being put to use. Since being in what is, fundamentally, a support profession, the most I can do is play along. That means, sadly, as another commenter admitted of himself, I'm in on it.

ralusek 9y ago

I mean the problem is that you're both probably right. You SHOULD add in tests and security, but you also very likely DON'T have time. Good code can be structured in a way that it's not going to be a nightmare to add in considerations of this nature further down the line, but with this sort of environment of "speed > everything" else, they're not likely to let you implement code well either.

gozur88 9y ago
>I mean the problem is that you're both probably right. You SHOULD add in tests and security, but you also very likely DON'T have time. But by doing the things that people can see and skipping the things they can't see you're effectively just lying when you produce a schedule. You don't do automated tests because it's a fun way to kill a Friday afternoon - you do them because they free you up to work on new functionality. So you're not really saving yourself time by not doing them. These kinds of projects are almost always disasters. Invariably the problem is someone in middle management undersold the cost to the people above him. There's not enough time to write the app properly, so they borrow time off the end (with interest) to make it look like things are progressing to the deadline. So you finish the first 90% on schedule and then flail around on the next 90%.

sean2 9y ago

I'm in my early 30s, so frequently called an older programmer and I've heard a lot of, "we don't have time". What I've been waking up to is that projects that estimate realistic budgets and time scales don't get funded. Everyone underbids knowing that the company/customer will continue to fund and extend deadlines for project after sinking so much effort into a buggy prototype, until the realistic estimate is reached and the product actually reflects all the "hidden"/"discovered" requirements (i.e. foreseen but not in the bid) including security, integration and test efforts. What's weird is that everyone, customers included, seems to be in on this.

gozur88 9y ago
I think that's true, pretty much. But the downside is they force an inefficient development methodology on you as you try to make the imaginary deadline.
imhoguy 9y ago
What you describe is often the scenario of do-everything consulting sweat shop building tailored or customized solution from scratch based on a single customer requirements. Management often lacks business vision and technological path. Front sales and techical people are randomly assigned and switched between ad-hoc projects with varying industry domains and poor communication chanels. I think only debt slave or masochist stay in such places for longer. Age doesn't matter. I would rather look for more focused software product companies with stable teams.
dennisgorelik 9y ago
Most of new features are useless, so it does not matter that they are buggy. Only consistently useful features require bug-fixing. It is better to spend more time fixing bugs on few useful features after they implemented and tested by users, than spend time polishing all features (including useless features) up-front.

mmt 9y ago

It's even worse as an old sysadmin, since my Groundhog Day permeates almost every part of the organization.. and I've learned to avert my eyes from the code itself and leave that nightmare to the Old Programmers. Not that any of this is surprising, since the lessons of the semiconductor boom and bust weren't put to adequate use during the dot-com boom and bust, so whatever new lessons we learned then still aren't being put to use. Since being in what is, fundamentally, a support profession, the most I can do is play along. That means, sadly, as another commenter admitted of himself, I'm in on it.