@falling: not sure why you're hellbanned either, but without some kind of introductory text or summary or anything it's just blog-spam at it's absolute minimum amount of effort. They're clearly not even proof-reading before posting, given the broken formatting (edit: apparently this has been fixed).
If you want to argue that increased visibility is reason enough for its existence, then you're arguing in favor of every single copy and paste job on the internet. If so, that's your opinion - there are definite benefits for increasing quantity. But I wholeheartedly disagree that it is good.
To be painfully specific why, it's making a static copy of something from a site which was built because static answers were deemed bad, and it's splitting the feedback for little or no gain (note how there are more possibly-valuable responses in Ars' comments, but they're not on SE).
That it was apparently done by Stack Exchange is even weirder - they're willfully contributing to data-rot, when one of their major reasons for existence is to prevent it. It has already fallen behind the original answer, which has some significant edits since this was posted.
It's a possibility. But it's being done under their name - that's almost the same thing in practice. And I would hope it's not an unapproved use of their name, so they're implicitly approving of what is done with it.
edit: unless you meant something like them having a SE 'user' to categorize posts? I think all Q&As are under CC, so they're legally capable of doing that, but it certainly looks to me like it's SE doing the posting, since that's how they display authors too.
I think the spreading of good SE Q&As is great. There are problems with it that essentially can't be resolved (stale data), but it does spread good information to people who may not have seen it otherwise. But this is sheer laziness, and ends up with something significantly less valuable than if they had just embedded the question in an iframe.
Hah! You're probably right. I'd be interested in the thoughts of the people running this show, if they'd drop in :| It would be an interesting debate, in any case. I'm really having trouble seeing how this (particular instance, not necessarily in general) is a good idea, or at all in line with SE's design.
I'd update my resume and start looking for a new job. I've been in this situation twice in my career and neither ended well even with me busting my arse making real improvements.
Agree totally. I came here to post exactly this sentiment and saw it had already been done. I have also been in this situation and I can say that this is NOT a technical problem, this is a political problem and the only person that is going to lose is the new guy - namely the OP.
Of course the problem has a technical solution but the huge red flag is that there is no consensus. This means that whatever solution is put forward is going to upset someone and guess who the target of that ire is going to be.
The only way this is viable is if someone with real power is backing the project and what he/she says goes.
Fully agree with the solution. What I don't get is how one ends up in this situation in the first place. "I am newly employed as the sole 'SW Engineer'...". How on earth did he go through phone screenings, interviews and finally accepted an offer without any idea of the mess he got himself into from day one?
Unless you're very senior, it is hard to know exactly what you'll be working on when interviewing for a company. And even when information is released, companies usually paint a rosy picture of your new position and responsibilities.
Can't really blame him. Unless you been through this sort of mess before it is very easy to see this as a lovely technical challenge where the SW developer is the knight in shining armour that will end up as the hero after he slays the technical dragon.
Of course that is the fairy tale and in reality the technical dragon will eat the knight and use his sword as a toothpick.
I have found a particular/simple solution very helpful and I am surprised that people don't talk about it (or perhaps don't know it).
The basic idea is to, try to spend 1 hour on each of:
1. examine the code very quickly (try to do it in an hour or so), and based on the scan to guess what the top 4-5 subcomponents of a system are.
2. do quick code examinations to figure out what each subcomponent is supposed to be doing, and how each subcomponent is supposed to depend on the other subcomponents.
3. Now modify the code to reflect the above components. At the simplest, just move code into new directories for each component, but at more detailed levels you can make sure that there is never any single source file that has implementation for more than one component.
Now you are done. You can clean up code more if you want, but do that slowly. Just make sure to not put new code in bad areas. Yes, you will possibly have spent more than 1 hour on each part. But you should have a much better grasp of the code, and the code will not keep on deteriorating.
I am not really talking about badly documented code or code with bad naming conventions, or other related problems. However, when the big problem is the 'spaghetti' (and cyclic dependencies) - this has really been the only solution that has worked well.
Slowly over time clean up the code and educating though examples and approachs and standards and all agreeing and understanding them would be a good start, nomatter the direction. Also if its viable to document, albeit organicly in a way that you have a process to control changes, it can only help. One day you will have it fully documented or cleaned up.
Slowly, slowly catch the monkey was a comment a COBOL programmer I worked with in the 80's would put in all his code (along with naming all his procedures after drinks, but lets not go there - shudder). I now, know why.
Knowledge based systems are great, but they do end up mixing the data into the code in a way that over time is fun.
I had to work on a real crazy bit of C code once that was larger than I cared for. I mearly found the parts that effected what I needed to do and changed that. It worked, no idea what most of the code did but the aspect of being to work with more than one radio controler was easily enough to change. No documentation and was a bit spag bowl. But it was a easy change and in many ways it was due to design of the programmer who had written it. He had allowed for such a change, not documented but was easy and changing a few variables mostly. Leason there is you can have code that makes no sence, but it gets the job done and if you need to change a particular part, if you can locate that part then you can read the effecting code and change what you need. If when codeing you plan ahead of possible future changes. Well nobody can ask any more.
If it works, why argue. If you can slowly and saftly make it work better then fantastic. Remember not all new wheels go faster or better than the ones they replace. Think about that incase you argue a rewrite. Rewrites for the sake of it one day and next you will be flying with the seagull managment.
Also worth factoring in that spaghetti code saves jobs and lives, I understand that joke now.
You can't teach old dogs new tricks. Introduce best practices slowly in order of priority otherwise if you overwhelm the old timers with lots of new coding policies that they don't understand then they'll just dismiss it all as useless bureaucracy.
Since the guys who wrote the original code are scientists or engineers, they probably learn new tricks all the time within their own profession. The fact that they realized that their code has become an unmaintainable mess and have hired a software developer to help them out seems to indicate that they might be open to listening to what he has to say.
If the software guy comes in and starts insulting the scientist guys' code, the game is over. If the software guy shows no desire to listen to what the scientist guys have to say, or learn anything about the problem domain, the game is over. But if the two sides can learn to work together toward a common goal, they might have a chance of success.
Every self-respecting Russian programmer will always try and convice you to rewrite everything from scratch. Regardless of the context. I'm pretty sure it's in their DNA.
You are young yet :) Virtually every Russian dev over 30-40 I know is like that. I am myself that way too. It always seems easier to redo from scratch than to waddle through someone else's code.
He can't do that, since he doesn't have the hundreds of man-years of domain knowledge that the authors of the code have accumulated. As a software developer, he probably doesn't know the first thing about how a chemical plant works. ("The program itself is a physical model of a complex chemical processing plant; the team that wrote it has incredibly deep domain knowledge but little or no formal training in programming fundamentals.")
Understanding 200K lines of complex code well enough to be able to rewrite it is hard enough, even if it's just pure database or graphics software. If it's about something you know nothing about you're going to have to learn something about the domain first, just to understand if the output you're seeing is anywhere close to correct. You're going to need to know whether some odd behavior of the code is essential to its correctness and must be preserved, or an accident of its particular implementation which can be changed or removed.
Also, you can't just dump some system that people depend on to get their work done. You have to maintain it and fix bugs while writing its replacement. Given that he's just a lone developer and doesn't have the budget or authority to hire a large team of professional hackers to help him, his only chance for success is to start learning about the system, adding tests and making small refactorings.
Sorry, but this is really bad advice. It is very tempting to redo something from scratch, but in doing so you will end up spending a very large amount of time fixing issues and adding details that were already done in the original code.
Oh yes, I have seen where re-writes are actually done. Developers start to talk about the lack of "scalability" and "maintainability" of the application with the best solution being to rewrite the app. I've also seen Java-to-Microsoft stack ports being bandied about. Generally it is a really bad idea but some of the decision depends on the language(s) preferred by the firm inheriting the app and the size of the app.
It can sometimes be the right approach. It's not a decision to be taken lightly, but it should be on the table.
Especially if your goal is not to duplicate the functionality of the old software precisely, but to provide a significant upgrade. It really depends on the requirements.
A important question you have to ask yourself above all others:
Is this something that is portable skills wise, will you learn about the subject and will that skillset be something of interest and marketable down the line?
Reason I ask that is if your not interested in it and/or if it is such a niche feild that the knoweledge you will gain on the subject is not portable. Well, unless its a pasion, just remember one important thing: probation periods work both ways.
It's a copy and paste of this question on Stack Exchange: http://programmers.stackexchange.com/questions/155488/ive-in... but with broken formatting, and nothing else.