|
knowing that their code smells worse then dinosaur farts?!
Honestly, I could not advertise myself as a competent software engineer, if I knowingly produced such excrement.
and yet these "senior" engineers are still employed.
 
modified 24-Oct-14 11:04am.
|
|
|
|
|
They may say the same of yours.
|
|
|
|
|
Yeah, what I've learned is, even though I consider myself one of the non-retarded devs, there are times I write retarded code. Like when under time constraints, etc.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: there are times I write retarded code. Like when under time constraints,
You can disagree with me here, but there is no excuse to write retarded code. Where I work, you can get into A LOT of trouble you submit bad/not working code into production.
My grievance goes beyond aesthetics or "code style", but rather with code that is so poorly written, it doesn't work properly.
|
|
|
|
|
Slacker007 wrote: You can disagree with me here, but there is no excuse to write retarded code. Where I work, you can get into A LOT of trouble you submit bad/not working code into production.
When I say retarded, I don't mean completely asinine. I mean not "perfect". There are times it happens. Is it great? No. I do like it? No. Is that just the world works? Yup.
If you're thinking something along the lines of, let's just say, not having a single point of reference, not using constants, not being consistent with formatting, etc. then I totally agree with you. There's never an excuse for that.
Jeremy Falcon
|
|
|
|
|
Slacker007 wrote: submit bad/not working code into production.
I would think the various testing phases should get 99% of "not working" code!
We do most our specification in UAT, get an idea what the user wants to achieve, build a POC, send it to UAT and actually get something from the users that makes sense.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: would think the various testing phases should get 99% of "not working" code!
You are correct, and it should. It is a combination of careless coding and careless testing by certain teams in our company. I am sure these guys know how to code well enough.
Burnt out and lost motivation, maybe, who knows.
|
|
|
|
|
Slacker007 wrote: with code that is so poorly written, it doesn't work properly
There are times that code is really poorly written but it works, as long as you don't touch it again. These are the ones that are mostly caused by time constraints IMO.
Although some people do write retarded code no matter what, because they are, let's say, not born for coding. I get aggravated a lot because of that.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Client: We need this and we need it now.
Dev: That will take 3 or 4 days to do
Client: We need it today or you don't get paid!
Dev: No way - only way I could do that would be to do a real quick and dirty - bypass the ORM , directly access the Db via ...
Client: <fingers in="" ears=""> lala lalalla lalala
Dev's Boss: The Dev said he could do it! nSo Doit Do it DO IT!
Dev: BUt it's just a quick fix, right, we'll re-engineer it straight away, right? In the next sprint?
Dev's Boss: Sure. <maniacal laugh=""> :rubs hands together:
Dev: I hate my life!
PooperPig - Coming Soon
|
|
|
|
|
I wrote an article along the very same lines on the subject of technical debt, which is what your point refers to.
There's nothing intrinsically wrong with taking a conscious shortcut if there is a justifiable reason to do so e.g. there may be a bonus for hitting a deadline or compensation if you don't. But as long as you repay that shortcut then there's not a problem. The problem is that you never get the time to go back and address the shortcut, as you are already onto the next shortcut etc etc.
[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
|
Been there, wont ever go back.
If I am the only developer that can provide the solution, my answer quickly become:
- Under normal time constraints. 3-4 days.
- If you rush this, I will "try" with no promises, but the COST will be 8 days.
If you are okay with paying for 8 days of my time to do it wrong, and then to fix it,
well of course I will do that.
If there is another option for them to develop it with, I ALWAYS let them choose that one,
when they want such rubbish.
|
|
|
|
|
Yeah - that's fine when you're 'the boss' and can decide what to do.
Problem is the majority of developers are in the 'do what the boss says' role without the options.
I recently had the situation that, with major issues in the codebase requiring fixing (35 second response times, frequent crashes, simple failure of functionality) we dropped everything and started a sprint - to change the fonts and footers on all the reports so they all look exactly the same
The main reason they weren't all the same was because the data required wouldn't fit on some of the reports otherwise.
Now, the developers could have stood their ground -- but they're being paid to develop and offer advice - so, advice offered, the choice is do it or move it.
Of course, teh ling term result of this sort of thing continuing is redundancy anyway ...
PooperPig - Coming Soon
|
|
|
|
|
I will add that the easiest way to make your boss fail is to do what he asks... Exactly what he asks, with no common sense applied.
I stand my ground, that even if you are just a developer... You have an OBLIGATION to do a professional job.
I stopped calling it "Kirk's Law", but I warned people: You CANNOT pick the features AND the DEADLINE. It is like someone coming in and saying, we break ground tomorrow, we need to build a full scale replicate of the Empire State Building, and we have 7 days! (Hey, it was built before, we should know the sizes, how hard can it be?)
Honestly, if you are HONEST and UPFRONT that it cannot SAFELY be done in the time given. Let them know that there is a 90% probability that the entire system will crash and data will be lost because of this bad decision.
Most clients are RISK ADVERSE. And this "Big Client" crap is for the birds. If you have to add a feature to a system being worked on. Can they REALLY get someone else in, up to speed, and have them do EVERYTHING you are doing, PLUS add this new feature? (if they can, then you are not worth what you are charging them, and they should go with someone else).
Clients will DEMAND whatever they want, but I am here to tell you, they do NOT LIKE the horror stories, and if they get even the slightest whiff that they are about to create a horror story for themselves, they usually shift away from the demanding stance.
In my book, the problem is that developers are too willing to say YES they can do something. I used to be that guy. In the end I was not happy, and the customer was not happy. I am no longer that guy, and DESPITE a few "difficult" conversations, the clients are much happier and so am I. Projects go online that require NEAR ZERO support. Because it was well-designed, well-managed, and well-built.
Honestly, if you told your boss YOU cannot do it in the time allotted, what is he going to say?
As long as you are being honest, you will change your organization, or you will change your organization.
==
PS: The report issue: As long as the client does not dictate HOW MUCH TIME YOU GET to do it, I am okay with them setting priorities. (But this issue was about Doing X in 1/2 the time required)
|
|
|
|
|
I'll see your scenario and raise you..
Biz Mgr: The Client says that we have to have the system do this.
Dev: Well it's not really how the system is designed work.. Who said we could do that and what are the requirements?
Biz Mgr: I'm not sure but this is a deal breaker!
Dev's Boss: Ok, well lets hash out the requirements so we can scope it out and get it into the backlog.
Biz Mgr: Great! Wait, what's a Backlog? We need this right away, Client rolls out Q1.
Dev: WHAT!? It's almost November! So we have to redesign a production system to function in a way it was never designed, for 1 client who can't even give us detailed requirements of how it exactly should work...and we have to have it done yesterday!?
Biz Mgr: Sorry, 6 weeks should be plenty though right? It's not like this a complete rewrite.
Dev:  Says to himself "Wow Biz Mgr and now an architect too?"
Having witnessed the recurring symptoms of 'clientitus' throughout my career, It has become much easier for me to "live with myself". Gives me an excuse to use more colorful comments in my code. 
|
|
|
|
|
Give an excuse to use non tested technology/methods/procedures in the field, to use dangerous practices, everything will crumb down sometime, why care? all those software are just my experimentation lab, I don't care anymore if it will crash in two days.
"You have to be professional" f*** this, they aren't being professional by accepting this sh*t from clients, that's why this is crazy work, everything is utter sh*t because of this endemic behavior of the managers, they always take deadlines out of their magic hats.
|
|
|
|
|
PIEBALDconsult wrote: They may say the same of yours.
No, they don't.
I am actually being called in to clean up their mess.
|
|
|
|
|
Slacker007 wrote: yet these "senior" engineers are still employed.
And posting in Q&A.
|
|
|
|
|
Richard MacCutchan wrote: And posting in Q&A.
Laughed so hard at this, my soda went out my nose. Ah, the burn. 
|
|
|
|
|
And posting "Articles" here as well... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And steal your profile picture
|
|
|
|
|
plagiarised ones?? Which company do they work for? 
|
|
|
|
|
Brainblaze, I think...;)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
They live by themselves in themselves for themselves, ins't it obvious? I think therefor I am sort of thing I guess
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
