|
charlieg wrote: This smells like nifty code. Nifty code is brittle. If it's difficult to understand a struct, you're doing it wrong.
I heartily agree. This struct defines the message format used by our in-house diagnostic tool. Our applications are multi-machine, multi-process, and multithreaded. Each process includes a small TCP/IP socket-based server that communicates with a client application. Code in the process uses the server like printf on steroids. The client in turn handles as many server connections as needed, displaying and recording them. The servers and this tool has been essential for both development and problem diagnosis in the field for us for the last 20 years. It's been maintained and refactored numerous times. We have systems in the field that are over 10 years old, so backward compatibility is an absolute requirement.
The good news is the code around this definition abstracts away the awkwardness of this definition.
Software Zen: delete this;
|
|
|
|
|
And the structure is just evil completely through...
If you have to stare at something like this - here's your sign.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Message would cause a name clash in the 2 struts.
So MessageOld, MessageNew
|
|
|
|
|
In a standup today, discussing a particular code repository. Sometime in the past, someone created a backup of one of the projects, then worked on the original project. Afterwards they checked everything back into repository, including the backup.
So my team is now working on this, and the developer was wondering whether this backup needs to be updated. I commented that if this is just a backup and no longer being used, we should just delete it. Keeping in mind that if it is still needed, it still exists in the history of the git repo.
So of course a big discussion began, with the other developer arguing that we don't know why it is still there, maybe it's still needed, etc. The final decision was to take this one instance to the main IT manager to provide "guidance".
Whatever happened to developers taking responsibility and making informed decisions? We are supposed to be senior developers, and capable of making a decision without having to have a committee meeting, or passing the buck to senior management.
If I was that manager and was asked that question, I think I would be a bit pissed off and have some serious doubts about this team....
EDIT
I should have remembered, this is a large government agency. And there is a huge mentality of covering you b#?! and taking responsibility for anything. I guess that is what they have us contractors for....
|
|
|
|
|
Is it causing any trouble?
|
|
|
|
|
Yes and no. Personally I don't care that much one way or another. I just find that this is a lot of passing the buck, and a non-willingness to clean up things that are not needed (a bit of YAGNI I feel).
However we do have automated scans that look at the repos and see which might need work, such as updating libraries and. Net versions used. Keeping this in there just generates false positives that then have to be looked at. And these projects tend to be floated around various teams that may not be aware of what these duplicated projects are about.
I am of the mindset that if I am working on a project, and find unused code, it should be cleaned up. Just more technical debt to deal with.
|
|
|
|
|
Yeah, I see that.
But, as you say, even deleted, it's still there. So I really don't see the point.
Where I am, we have an issue where there are database tables which are no longer in use.
I want to leave them there. That's what I do.
The DBA says we should free up the disk space they use.
I said we can TRUNCATE them to free up the space, but that DROPping them isn't going to make a difference, and that they can always be DROPped later.
So they said OK, who'll do it?
I said I'd write a script.
I wrote a script, ran it on the DEV database, it was fine.
But no one will man-up and run it on UAT or PROD -- I can't, I'm the developer.
I think my script has been sitting there for a year now. :shrug:
|
|
|
|
|
hardware is cheap, data is priceless.
As long as you document the tables no longer in use and WHY, for Jesus', Joseph's, and Mary's sake - document why! (sorry, I miss my dad. When I really did something stupid his go to profanity was JJ&M  )
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
If you're working with a government agency I think you'll find this transcends fields.
The attitude of working lights on at 9 lights off at 5, and not caring more than you're being paid to care is a foreign concept to many of us working in software development, but it is de rigueur in government, at least in the states.
I think part of it is the methodical yet inflexible way they do performance reviews. You simply have to check all the boxes, and you don't really get rewarded for going "above and beyond" - you get rewarded for seniority, which leads to a lot of people simply keeping their heads down.
I don't think it's all a bad thing. A lot of private sector jobs have a culture that "rewards extra effort" but what it eventually devolves to (if it ever was anything else) is a culture of overworking employees. That's almost impossible to do when you don't reward going above and beyond.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I agree, and I dont think there is much difference with gov't agencies here in Canada either.
In a similar vein, I find It shops that are unionized, even in the private sector, have a very similar mentality. I view myself as a professional, and work hard to keep my skills up to date and make an effort to keep up with technology changes. But I find a lot of unionized IT workers take it for granted that the company or agency they are working for will provide the time and money to train them.
I used to MS myself as you did I believe, and I remember working 14 hour days to meet goals and such. Destroyed my marriage in the end. Now I work as a contractor, and I find it much more rewarding. And I get paid for all my efforts. I would have to be given a pretty lucrative offer to go back to being an employee again.
|
|
|
|
|
Assuming it's in source control, why would anyone need to "take a backup"? 
Sounds like the developer who did this needs to learn about branching...
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Exactly. Mind you, some of this code is really old, and I think they started with Visual SourceSafe which had a lot of problems.
There are literally hundreds of these repos, and we use a number of automated processes to scan and report on these projects. Having the else extraneous projects in here causes all sorts of false positives as to the state of the code. It's important to have accurate reporting on all of these, as it impacts budgets and allocation time and developer resources to address these.
But as I said earlier, there should be some level of common sense on cleaning this up. As senior-level developers, there should be a trust that we can address these things without requiring convening a committee, schedule meetings, and getting senior management to make a decision for us.
This is just another form of YAGNI, but instead of adding code that isn't going to be used, it is removing code that is no longer used. And as developers we should address technical debt to clean up up any project we are working on. I liken this to the Boy Scouts, where we should leave the campsite/project cleaner and in better shape than we found it.
It is very common here for multiple teams to work on a single project. Add to that employee churn. So making sure that the code is a clean, concise and understandable is important for whoever has to look at the project the next time around.
|
|
|
|
|
by any chance do you work at the IRS?
[^]
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
No, this would be a Canadian government agency....
|
|
|
|
|
Close enough 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
|
seems like a bunch of babies
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Yep, I can hear it now:
'FFS, It's a ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing backup! If YAGNI just get rid of it and quit wasting my time!'
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Well, that's the thing. It will still exist in the repo, but people don't have to keep "tripping" over it, wondering why it is there. It isn't like it is forever lost....
|
|
|
|
|
It will eventually be forgotten, but that is the way of software. No one will know it is there in the repo.
This seems like more of a labeling situation than a branch.
With this team, if they had created a branch, then no one would have the guts to merge it back to the mainline.
|
|
|
|
|
Andreas Mertens wrote: Whatever happened to developers taking responsibility and making informed decisions?
Informed decision of course is based on understanding that the point of the company (lets use that as the stand in for whatever the organization might be) is not to 'write code'.
But rather to provide a solution that meets the needs of the company. And doing so in a way which enhances the actual goals of the company. Company goals can include things like costs (storage, maintenance, etc), performance, regulatory guidelines, customer needs and desires, higher management goals, marketing needs, etc.
So how does deleting it meets the company goals?
Now one can make the argument that cleaning it up increases some developers morale. Morale is important since it impacts retention. But could be some other developers that might have some concern, especially if the system is complex, that deleting this might cause problems. And without some other specific company goal being met it just is not worth that risk.
|
|
|
|
|
|
That's truly nutty.
Check out the name of the 4th param to the other make unique filename function:
BOOL PathMakeUniqueName(
[out] PWSTR pszUniqueName,
UINT cchMax,
[in] PCWSTR pszTemplate,
[in, optional] PCWSTR pszLongPlate,
[in, optional] PCWSTR pszDir
);
Long Pointer to a null terminated string which is the name of a Plate??
I think they meant Template.
|
|
|
|
|
My understanding is that the 3rd parameter was used for short 8.3 filenames and the 4th for the long filenames. Probably someone was "witty" and invented "longplate" to differentiate from "template".
Mircea
|
|
|
|
|
Ooh! A punster! Very nice
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
