I am a junior developer, but my experience so far has been exactly this; arbitrary deadlines, poorly defined or no technical specification and worst of all, no room for testing or documentation, yet still somehow expecting it to happen in the end.
It isn't a manager's job to provide you with well defined technical specifications. Figuring those out takes an ongoing iterative process involving input from multiple stakeholders.
One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
Technical specs no, but well defined product requirements definitely yes.
I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
Engineers are not black boxes which take well defined product requirements as input and produce code as output. That seldom results in good products in the real world. A competent engineer has to understand the business domain and be intimately involved in the requirements definition process. The product owner (or product manager for higher level stuff) has the final authority on requirements but it's a two way conversation. Otherwise too many things fall through the cracks.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Shaping the specification I would certainly not have a problem with, but because I do not have a direct communication channel with the client, I must rely on my manager to be a good, accurate "translator" between me and the client and the other way around.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
Yes that is exactly why lean agile development was invented. It should be standard practice in most development organizations by now, but yet people still want to believe that it's possible to reliably anticipate what customers want far in advance. Sometimes you can guess right but that's a risky proposition and seldom repeatable.
To keep you iterating, to ensure iterations are productive, to wrangle those disparate stakeholders into evaluating the "now" and to turn criticisms into the "next".
I wish they would let me get involved in the process more. I know that doing one feature might take one week or two. However doing it another way I can probably do it in a day and get 95% of the functionality needed.
That is interesting. Which parts of the process would you want to be involved in, and why would it make such a difference in the time needed for the delivery of the feature?
Being involved in the discussions about what features we are going to implement usually.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.
In my experience, the very best value comes from people who are simultaneously technical experts and domain experts. This lets them short circuit the vast majority of communication overheads, because they know both the user requirements and the implementation details simultaneously.
Well look at it this way....if all of those things were to be provided to you, they could probably find someone to do your job for 30% less. There are some upsides to software being a total shitshow.
I would, as an engineer, be okay with that. As you imply, that makes me considerably more valuable. The problem is that I'm never given time for any of it. As soon as "MVP" status is reached, the feature is launched, declared a victory, and then we move on to the next thing, while the users note the half-assedness of the delivered product, and never looked on again. Meaningful work (aside from the occiasional bugfix) never occurs, as it can't ever get prioritized higher than the current MVP of the day.
Sounds like planning economics in a miniature kingdom.. does not matter whether the product sucks, as long as it gives bragging rights to the duke.
The problem is that most of management, contrary to there claims, are totally detached from market forces as long as a company has a cash cow.
I wonder how much more happens only after you say "fuck it I'm doing this thing that we've desperately needed to do regardless of manager approval or sanctioned time."
When the whole dev team is in on it it's actually not too hard to bake in extra time for the unseen things by just everyone taking longer than they would if they were doing purely what the managers wanted. (Though ideally by doing some of the unseen things the total time for future work will become less than it would have because you don't drown yourself in tech debt by trying to do the PM's MVP only every time... It's nice to have a PM who understands that tradeoff.)
You shouldn't worry about software being late. Work at a good clip with the time you have. This is just the norm for this industry and the only managers who presume otherwise are themselves novices.
Unfortunately, one needs to get a bit of experience (and risk early burnout) before they cotton on to that fact.
My first real junior dev job [1] gave me an ulcer. I only relaxed when I realised what you allude to: people yelled at me and complained about my working pace (and the fact I didn't... smile) but there wasn't anyone else willing to do the job I was paid a pittance to do, especially not with that money. I could just take my time and do my best in the time I thought was appropriate and let middle management go screw themselves. Poor bastards anyway- they were the de facto product testers so they probably had it worse than me in the end.
[1] In other words, working for a company that didn't give a shit about me and just used me in a "human-wave" sort of approach to development. This also came after a stint at a company that treated me fairly and gave me a full "software engineer" title, no "junior"s, so I had the chance to observe the difference between the two models very closely.
"Noted Good Developer A thinks it will take at least 3 weeks for you to complete this feature request, but we're being pushed to get it out in 2. I think you could manage that, but what about you? Can you do it or not?"
Yes. I've been getting thrown into the team lead position quite a bit as I've gotten older.
I get tasked with delivering arbitrary deadlines for impossible features and timelines to my team and managing the outcomes.
There really are no other reasons for some of these deadlines other than higher mgmt. competing against each other. There are no business reasons.
Long ago I just started ignoring them and giving my team deadlines that were both reasonable and obtainable. I don't want anybody stressed on a daily basis.
