How can I ask for better technical requirements for the tasks I get assigned?

Question

How can I ask for a better definition of the tasks I get assigned?

Today the tasks are basically just a user story without any technical definitions on how it should be solved.

They expect me to find the solution by myself and once it's solved they will check if that was the way they want it or not.

This is somehow OK, but the problem is they change their mind between every task. So if I take the feedback from task A and apply it to task B, then suddently they don't want that for task B and can even suggest it to be solved as I did in task A before the feedbacks.

I have been working on cleaning up and implementing new functionality in a very central part of the product because it's very difficult to maintain (due to messy code; one class has more than 4k lines).

During this work I have implemented it the same way as it is done in other parts of the application and split things into smaller parts, so it should be easier for new developers to understand the code and it's more flexible to make changes without breaking the whole monolith.

But doing so, and talks during the development, make it clear they don't want it to be solved how it's solved (splitting up the code was agreed upon) other places with basically the feedback "we are now going reinvent the wheel and it might not be right to do it as it's done other places in the application".

This makes me kind of frustrated because I have no idea what they want and only thing I know by far is that they don't want it the way I'm solving it.

How can I ask them to write the tasks for "dummies" where somebody actually have a plan for how they want it to be solved?

Some background

I'm currently working as a 'sub-contractor' for a company because they are not able to hire the staff they need to be part of their team. During my time in the team their best developers have quit. Sometimes I wonder if this behaviour is because they feel threatened by "external people".

I have now canceled the contract with them and I just want to complete my work and leave in a clean way without looking like I'm just arguing with them.

Information added after asking the question

I have also made technical documents describing how I plan to solve it. This has never resulted in any feedback or yes/no, and if I ask about it when the task is completed, the answer is they have so much to do, so there is no time to go through it.

Answer 1

How can I ask them to write the tasks for "dummies" where somebody actually have a plan for how they want it to be solved?

You can't.

The reality is, they don't know how they want it solved.

Take whatever you are given, ask a lot of questions, write up good notes and share them, implement the solution as best you can, then don't be surprised when they want changes.

Plan on subsequent change. Learn to be less frustrated or learn to live with the frustration.

Answer 2

It can sometimes help a lot to put together a mock-up/"stub" simulation of your proposed solution, show it to the customer, and ask "Is this what you want?" That helps resolve the missing details before you spend too much work on what may be the wrong solution.

The risk is that some customers don't understand that a simulation does not mean a solution is close to complete. Someone actually came up with a user interface style for Java that makes the display look like it was sketched on a napkin to help emphasizing that what's running is only a code sketch...

Answer 3

In your question you refer to "they" several times, but you don't say who "they" are. In software development there are often lots of people involved with different skill sets and different responsibilities. Reading your question it seems you are using "they" to refer to a few different people with differing skills and responsibilities. They key to your question is to understand this landscape and where you fit into it.

The normal way of things is that a product owner writes a user story that defines a task to deliver business value. The story often doesn't have technical design in it at this point because it is supposed to define the task and the business value; not how the solution is implemented. Likewise the person who wrote the story should not feedback on to the suitability of how you implemented it, unless there is an impact on the story, eg some NFR or acceptance criteria are not being met.

With the above in mind, the actual technical design is normally handled by a different person. This may be a technical/solution architect, a tech lead, lead developer or whatever. The person and role varies, but it should at least be clear who has design authority. This is where we get to the crux. It appears unclear who has design authority, however from what you have said it is not you, but someone on the client side, and that person isn't giving you guidance until afterwards. They aren't telling you in advance what the implementation looks like, they are coming back afterwards and telling you what you've done isn't right. This is bad for everyone. It means work is repeated and costs more, and isn't a conducive environment for job satisfaction.

What I suggest is that;

1. You identify who is the technical design authority for work to be done.
2. You proactively seek out guidance and approval from this person or persons. This could mean asking them for a design, or taking a design to them for approval/signoff. Do this on a story by story basis.
3. You document the design and the approval and create traceability. This could mean putting it on a wiki page and linking from the jira story, but whatever works for you and the client. You could even incorporate this into the jira lifecycle with a design/approval stage. Don't start coding until this is done.

Answer 4

This is quite often what you will see as a (sub)contractor. The company generally doesn't see any strategic or long term value in making sure you understand all of the details of the product because you are viewed as temporary. In some cases they specifically don't want you to know that much about their product.

Your job as a contractor is to complete the tasks assigned. For each new task you should ask for specific details to be performed/implemented. You shouldn't make assumptions about how this task is related to previous ones until they say so.

As long as you are contractor, you shouldn't expect to get much inside information about how everything works and what their larger plans are. Some companies may try to hire contractors who have shown good skills. If that happens, then you'll learn about a lot more of the internal plans and information.

Update based on comment:

Each time you get a new task you will need to ask how that task should be implemented. There is no magic way to phrase the question. Hopefully, over time they will give you a better overall picture so yo can be more autonomous, but until then, just ask every time.

Answer 5

I think you may need to be a little clearer on setting expectations of what you are going to do before you start working.

Information added after asking the question: I have also made techinal documents describing how I plan to solve it. This has never resulted in any feedback or yes/no and if I ask about it when the task is completed, the answer is they have so much to do, so there is no time to go through it.

For me, the main issue you have here is not requiring agreement with the proposed methodology prior to starting work. You are coming in externally to the company and need their buy in on how you will make your change before you start.

Rather than just forwarding on these documents and starting even if they haven't replied, try something like this in your communications:

Bob,

Please find attached a document that lays out my proposal of how I will implement FeatureA. The estimate to complete this work is XX days.

In order to meet your deadline of XX Jan 2099, I will need to start work by next Monday. I will not be able to start this work until we have agreement on the implementation plan.

I look forward to hearing from you.

GreenMountains

And then if you haven't heard within a reasonable timeframe, follow up with them:

Bob,

Just a reminder that I will be unable to start work on FeatureA until we get agreement on my implementation plan. Please can you get back to me on this by XX Jan 99 otherwise I will be at a standstill.

GreenMountain

Answer 6

Keep having meetings with them until they give you a well-defined list of deliverables.

If they change their mind, then create a change-request process and spend your time doing that.

At the end of the contract, you present all the work you've done and then that's it. If they wasted your time having vague ideas and changing their mind, then that's their problem. You just need to record all of it down so they can't accuse you of doing nothing.

Answer 7

The issue here seems to be that you're getting given requirements, solving the work in a way that satisfies those requirements, and then being told that actually there were hidden requirements around how you met those other requirements.

---

So, there are two ways I can think of how this situation could have arisen and your response should depend on which of these you think is relevant:

Option 1 - You're a Junior Dev

Your solution meets the functional requirements but it might not satisfy some of the following implicit requirements:

• Your code is messy
• Your code is unperformant
• Your code doesn't conform to SOLID principles
• Your code doesn't conform to the architectural/code standards.
• There's some context you're missing as to why this other solution is better in your business context.

In this case, you need to speak to whoever your lead is and work with them to learn about these things and how your future solutions can conform more closely to these. It's easy for a junior dev to think they're doing something in a similar way to other parts of the system but they're actually missing some key component or context through no fault of their own. Pair programming or thorough code reviews are good options here.

Option 2 - Your Leads are Control Freaks

This situation arises when your code is perfectly good, meets the requirements, and doesn't diverge in any meaningful way from the standards set out by your team. In this case, your leads just don't want to give up their control over the implementation.

Unfortunately, this situation sucks because it boils down to a lack of leadership skills and emotional maturity amongst your leads. So dealing with it is likely going to require walking a fine line so as to avoid upsetting anyone.

I'd suggest trying some of the following, how you approach it will depend on how close you are with your leads:

• Ask them to articulate why their solution is better than yours.
• Ask them if your solution conforms to the standards.
• Ask them if the standards need to be adjusted so as to align everyone with their way of thinking.
• Tell them you feel that they're undermining you and that you need them to trust you to deliver on work in a professional and technically sound manner.

You should always approach this with an open attitude towards learning. Even as a more senior developer, you could still have a missing gap in your context or knowledge that they can fill in. At which point this issue somewhat becomes moot. However, if it truly is just that they're undermining control freaks, then you need to be willing to stand up for yourself and have an honest, frank conversation with them.

Remember (in most companies at least), you're paid to take business requirements and transform them into a technical implementation, you're not there to just type code in that someone else has told you how to implement.

---

Good luck!

Answer 8

they change their mind between every task

This is called 'moving the goal posts' and 'making you hit a target in the dark'. Unfortunately, not unheard of in software development, esp. large companies where the left hand doesn't know what the right hand is doing. It's very common sign of bad or clueless product/project owners/managers, and a toxic culture/environment.

This makes me kind of frustrated because I have no idea what they want and only thing I know by far is that they dont want it the way I'm solving it.

You need to (in writing) explicitly demand that they clarify why they don't want you to solve the problem the way you propose, and demand for an alternative way. CYA. Always document. Paddy lays out some very good templates for wording that without proper user stories, specifications, and acceptance criteria, you're not gonna be able to build anything successfully. You're the constructor, and you gotta have clay to make bricks, and you gotta have blueprints to build to house. Same goes with building software.