141–150 of 346 posts
Does this product work? if so, its doing its job. It may not be pretty, it may not be maintainable, but these concerns are orthogonal to its value.
Earlier quoted context omitted.
Yes. "Human Resources" is quite literal. Management discuss allocation of resources (i.e. engineers) to teams, open REQs (requisitions) for resources, etc.
Where I work, "Human Resources" is just in charge of benifits/payroll/etc. Assigning people to projects is done by the resource manager, a completly unrelated posistion.
Some pitfalls you may expect:
1. You find some crazy thing that makes absolutely no sense happens in the code for some specific inputs. You remove the craziness, and someone complains that an essential feature just broke. When the essential feature is explained to you, you find that its implementation is batbarf crazy, and that although it would have been easily implemented in a more straightforward way, someone important, somewhere, is redefining inputs and re-interpreting outputs in some special cases to get a feature they needed and no one had time to implement.
2. You find some crazy thing that makes absolutely no sense happens in the code for some specific inputs. Based on your knowledge of the many pitfalls, you ask permission to fix it. The more experienced person whom you ask explains that the input conditions to trigger your bug are so rare that it makes no business sense to waste any time to change it, it's not a priority, and you will understand things better when you have more experience, and why are you wasting my time asking me if you can change it when 85% of changes in this code base introduce new bugs (because it is such a mess)?
3. You find some crazy thing that makes absolutely no sense happens in the code, not for just a small subset of inputs, but for quite typical cases. You remove the craziness, and then you learn that a 'workaround' is in place, perhaps including both other software and user procedures. Lots of people are earning a living doing the workaround, and they don't want to change.
4. You find some crazy thing that makes absolutely no sense happens in the code. You remove the craziness, and then you learn that some other system is now out of balance with yours or fails to run with the data it gets from yours. No one anywhere can figure out why, but you caused the problem.
5. You find some crazy thing that makes absolutely no sense happens in the code. You remove the craziness, and then you learn that your chief accounting officer thinks that he is a genius because he found a way to turn craziness into quarterly earnings, and he is not happy with your fix, and the auditors want to talk to you.
6. You find some crazy thing that makes absolutely no sense happens in the code. You remove the craziness, and then you learn that your CEO's brother earns a commission or royalty on the craziness, and he's not happy.
7. You correct a spelling error in a report heading, producing numerical errors in twenty-seven downstream reports.
So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects. Every software company has these projects and many developers have been in your position. As long as the software is…
> The fact a new resource (you) has ... I am not familiar with this lingo. Why exactly is the OP a resource? Is this usage of "resource" common in business speak?
Earlier quoted context omitted.
Where I work, "Human Resources" is just in charge of benifits/payroll/etc. Assigning people to projects is done by the resource manager, a completly unrelated posistion.
I manage my team. When I discuss projects with my manager and the senior engineering leadership, they will almost always refer to staff as resources, e.g. "team X needs a SOA resource", "team Y needs extra QA resources" and so on. It's distasteful to me; I always refer to my team and other engineers as engineers or by name, not as "resources."
Are you working at my company? Ok, more seriously: that’s the way existing code is about 90% of the time - it’s the reality of working in our field. It may or may not reflect on the original developer. Maybe they were learning a new framework. Maybe they were rushed. Maybe it was originally intended as a prototype but ended up in production. Maybe the requirements have grown or changed significantly since it was impl…
So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects. Every software company has these projects and many developers have been in your position. As long as the software is…
It can also put you in an awkward position -- especially if the prior developer has a grudge against their code being rewritten -- as any bugs that come up can then be blamed on the rewrite effort, whether or not that was actually the cause.
Spaghetti code eventually collapses on its own, as every change starts taking longer and longer than expected, as well as introduces more and more bugs (and fixes for those introduce more, and so on). Once this starts happening, that can be the impetus to actually do a real rewrite effort, but one with a business case, management and hopefully the other developer(s) behind it.
Until then, a rewrite is a lot of effort that, at best, if you do a great job, is basically invisible (beyond the code level), and at worst either becomes a scapegoat for or the cause of many other problems.
To change the work I suggest communicating with the people around you:
Talk to the previous developer, explain him/her what anti patterns are, why testing is important and perhaps venture into things like solid design or design patterns. Is he/she willing to listen/learn? Then he/she might also assist you in communication towards management. If not, then I personally wouldn't go to too much length to save his/her ass.
Communicate to management and talk their language as much as needed. Talk about what the cost of maintenance is and why finding bugs in production is so much more costly then while writing unit tests. Talk about the cost of change in this versus a well designed and tested system.
Then decide with management and hopefully the other dev what to do.
Earlier quoted context omitted.
Rewrites are riskier when requirements need to be reverse engineered from the current solution, or if requirements are complex. When requirements are simple, rewriting should be simple. This should at least give you the opportunity to contain technical debt to the most complex requirements. To say "everything is complex therefore we cannot rewrite anything" is pretty implausible and mediocre.
I disagree. Rewrites are risky because you're changing code that has been working for some time. It is easy to introduce bugs into a sufficiently complex system when refactoring. "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it." - Joel Spolsky
You don't want to live in this hell during the rewrite, trust me!
(Oh, and another tip: if your management authorizes the rewrite you propose easily, it means you are SEVERELY UNDERPAID... the time of good devs always costs to much for rewrites to be worth it, unless the dev cut a really bad deal on hiring)