The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
A colleague was just rewriting some code that broke due to new/different behavior in an updated JVM. He was nervous about doing it since it was a critical function, but it had to be done.
I recommended that he enumerate all of the affected classes (hundreds) and dump the state with the old JVM. Apply the update and code changes and dump the state again. If there really was no impact, the before and after would be the same.
This is a typical practice that I do all of the time when refactoring to add a feature. The refactor should NOT change the results at all. Once the refactor is complete, then you add a new feature and you should see the expected changes.
He did that and found where his new code was producing better results because it fixed a rare but unreported issue in the older code. Now the new code can run any on either JVM and produce the same results.
That's only doable on certain types of software. In highly user configurable, very broad software products, there's no practical way to do that.
And of course we aren't just talking about refactoring. In many cases it will require jettisoning out of date tools that have deep roots in the code base, and/or rewriting large chunks of it that might contains really complex domain knowledge.
I've got a mix of old projects needing new features and new projects that my customers keeping coming up with. I keep having nightmares where a line of end users are waiting in front of my desk, when another comes in and breaks line to ask for another report or program tweak...a fight breaks out and I find myself paralyzed...then I wake up!
It's the new stuff that seems to take forever, mostly because there's no roadmap...unlike the rest of you, the only project specs I've ever gotten were handwritten on scratch paper or bar napkins...if I'm lucky, there might be a drawing!
Personally, I'd rather add features/fix bugs in existing projects than work on new stuff.
When asked, I always give multiply a reasonable time estimate by 3.
In classic waterfall (the thing before agile/nonplanning/adhoc) writing specs is the devs' work. From that, a basic design is formed, and from that, a technical design. AFAIK, agile skips that and goes directly to implementation.
Makes estimating so much harder; it's like guessing at what date you finish the book filled with sudoku-puzzles, and putting a price tag on it. That sounds a lot like gambling
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
That should NEVER be the devs work!
Especially in a waterfall environment, a business analyst (or more) should talk to users, stakeholders, etc. and only when it's finished hand it over to development.
In fact, if a developer strays from the written specs a tester should make note of it and either the software should be fixed or the specs should be changed accordingly by the analyst.
A developer is probably the least suitable person to write specs.
Agile doesn't skip it, it just doesn't plan too far ahead.
It's more like, let's write the specs for this particular feature.
Which features are getting specced or built next is up to the product owner who decides on priority (also with input from users and/or stakeholders).
The specs are then made into stories (or perhaps the stories make up the specs) which are estimated by the developers.
If any story isn't fully clear it goes back to the product owner who can then try to clear things up, probably by talking to the users.
In agile, you also don't estimate time, but complexity, in terms of story points.
The story should be done by the end of the sprint (usually two weeks) and every sprint can have x story points.
Estimating anything else than complexity of user stories isn't agile, it's a team trying to do agile in an otherwise waterfall company.
Consulting must be a different beast. I am the analyst, stakeholder, developer, support department, and tester. I write my own specs, usually on the fly! Unfortunately, I am also in charge of the documentation.
That can work for small companies or small products or products that are your own.
When working for bigger companies and with demanding customers you can't get away with that unless you can clone yourself and work five weeks in a week
I've been there too and it has its merits