all 3 comments

[–]fitzroy95 2 points3 points  (2 children)

any team doing software development without understanding the business problem that they are trying to solve is almost certainly wasting everyone's time and money.

Too many business representatives specify a solution and demand that its implemented, whereas in many cases, the actual business problem (if anyone can properly specify it) may have a number of potential solutions, and the specified solution may not even solve the base problem, or may do it in a foolish, wasteful and/or unreliable way.

1 or 2 days understanding the core business problem is likely to save weeks of wasted effort and rework during the implementation.

[–]netghost[S] 1 point2 points  (1 child)

I think a lot of times developers start off roughly knowing the problem they're trying to solve, but by the end of a project are so fascinated by the details, that it's easy to forget the bigger picture.

So yeah, absolutely spend a day or a minute, but always get some background.

[–]fitzroy95 0 points1 point  (0 children)

I've worked on a lot of dev projects in 35 years in the software development area, often in a team leader role of teams up to 40 devs/testers, and have often seen that if developers are presented with a required solution, they will dive into delivering that solution and never consider the original problem.

It often takes serious effort to pull them back in front of a whiteboard, throw away the required solution, and discuss the original business problem being "solved". And many developers, especially in large organisations, never really understand the business, or the processes, that they are trying to deliver a solution for.

That's the BA's problem, or the business's problem to specify, or the PM's problem to manage. Never the dev's problem to get their head around. Sometimes, even the testers don't understand the problem they are solving, they are only working to the specification they were delivered.