9 ms·

"Not so much on how we can more effectively understand requirements and translate these into code." The first step to understanding requirements: There needs t

"Not so much on how we can more effectively understand requirements and translate these into code." The first step to understanding requirements: There needs to be a requirement worthy of the name. Because let's face facts: programmers are quite often confronted with "requirements" cooked up by some "stakeholder" that don't even describe the problem domain, much less a path to how it should be modeled. A lot of the spaghetti that contemporary production code ends up looking like far too often, is programmers having to play a stupid game of "chase the nebulous and ever changing 'requirements'". Once you develop for A but then B is required as well, and the architecture didn't anticipate that, you may be able to go back and change it ... or not, because usually the requirements change, but the deadlines don't, and good luck doing the same, or more, work all over again, in half the time. Yes, programming is a hard problem. It really is. But it is also quite often being made harder than it needs to be.

atoav 3y ago
Programming is a lot like design - the customer tells you they need a design for their product, but they don't know what design they need, just what design they want. Now of course it falls back on you if you give them what they want and it doesn't work well. - there are many ways to tackle the same problem, many of them work okay, some of them work well and look nice, some of them work well, look nice and are easy to manufacture and maintain. But it also has to be the solution they need and one where you can convince them they want it. Finding a good solution is a lot like finding the biggest common denominator of a large set of numbers. As someone who worked in design before I can say that the most work and stress for me was bringing the clients up to speed, so I can communicate to them about the designs on one level. That meant explaining to them why their primary-color-powerpoint-comic-sans-poster communicates things they do not intend communicated.
- saghm 3y ago
  I suspect that this sort of problem is present is a _lot_ of fields; it's not a programming problem or a design problem specifically, it's a human communication problem, and those can make just about anything more difficult.
  - atoav 3y ago
    Exactly, just think about any construction site on earth where throughout the construction they realize that they actually need windows or electricity.
esskay 3y ago
I've just spent the last two days building out a system based on an API created by our clients internal dev team, only to have both the project manager and client throw in a massive curveball they knew about but neglected to mention - the API's been rewritten and replaced with a new one with a vastly different architecture. That's ~12 hours of work down the drain and one demoralized developer. It baffles me how this kind of thing continuously happens everywhere. Part of it seems to be that despite how many times you explain it to stakeholders, they don't seem to grasp that development takes time, and altering the plan mid way through is not only incredibly distracting but comes as a mental blow to the developer.
- imetatroll 3y ago
  I think it is more that they don't respect developer time.
  - ghaff 3y ago
    Any project of any size with any degree of coordination ends up with considerable wasted motion and "do what I mean not what I literally said." Maybe this wouldn't happen in an ideal world. We don't live in an ideal world. Even rigorous efforts to specify requirements (e.g. waterfall) didn't work very well and it's pretty much the definition of iterative development of anything that you throw a lot of stuff out but hopefully not big chunks (which 12 hours is not). That would be spending a month of something to find you were on the wrong track.
    - saghm 3y ago
      I think the point is that nothing about this is really that specific to programming; what we're talking about here isn't an instance of programming being hard but effective communication being hard. The parts of software development that are time consuming aren't very intuitive to non-programmers because there isn't an obvious way to show tangible progress, which makes it very hard to track externally, so it relies more heavily on verbally communicating the current state of things, and that introduces the potential for a lot of misunderstandings.
Scarblac 3y ago
But all that is part of programming. It's not made harder than it needs to be, it is that hard. Because exploring the whole problem space with the stakeholders and deciding together what the software should do is a central part of the problem of programming. And it's ignored by everyone, the stakeholders don't realize it's a problem, the programmers know but think it's not their problem, and nobody includes it in estimates or plans the required time and meetings for it to happen.
- dragonwriter 3y ago
  > But all that is part of programming. Nah, its systems analysis, a field which is largely either forgotten (in the “cross-functional means everyone is a nobdifferentiated developer” school of Agile teams) or replaced with “business analysis”, whose practitioners have less relevant skills (particularly, systems analysts were experienced programmers with additional process engineering skills, while BAs are nonprogrammers in a role that is often structured more as stenography than engineering) and “software architects” (who have a closer skill set to systems analysts, but have a role with a simulta!eously more abstract and narrower, implementation-focused orientation.) Systems analysis requires (or at least benefits from) an understanding of programming, but its not the same skill
  - arethuza 3y ago
    Good BAs that have domain specific knowledge are really valuable.
    - dragonwriter 3y ago
      Sure, my issue is with the culture and idea of what is needed that has driven the structure of the workforce and the way many orgs treat the role.
      - arethuza 3y ago
        Sorry - I was trying to agree with you :-)
sancarn 3y ago
I feel like communication of requirements is difficult too. I'm currently a business end-user, with developer experience, who is maintaining legacy VBA technology, trying to get an official system produced by a 3rd party contractor. The requirements started out truly quite simple - we want a database and a nodejs web server. But Technology are gate-keepers. We're not being trusted with what we want, or with that level of control over the system. Which then starts this cat chasing mouse thing of what the Technology will allow and what the business wants. I've always vouched for "Internal IT" - specialised developers who work closely with the team, even doing the jobs users do, to self-identify what technology is required and kickstart these projects. Edit: in this particular project, I handed over numerous diagrams of how the system should be architectured, and Technology BA's came back with a proposed set of technologies (SASS) that simply wouldn't be technically feasible... It's really made me lose hope.
c22 3y ago
I think there's something to this. When I write programs to solve my own problems I find the process easy and enjoyable.
- sebastianz 3y ago
  How big are the programs, how often do your requirements change, and how many years or decades do you develop and support them? Because tiny one time programs are indeed fun for a while until they “grow up”. :)
  - c22 3y ago
    Small, rarely, and usually for one or more decades :)
Hermitian909 3y ago
This actually touches on one of SV's durable advantages in the software world: the realization that if you want good software your engineers must be involved in the requirements gathering, design, and scoping phases. Critically, the business understands that engineering is the most authoritative voice on cost and since all business activities should pass through an ROI analysis filter engineering needs to be in the room. Keeping engineers in the room then adds a positive feedback loop: as they understand the business better they start to offer up new opportunities to the business that have surprisingly low cost. (I will caveat that for sufficiently solved problems you can generally involve software engineers less)

atoav 3y ago

Programming is a lot like design - the customer tells you they need a design for their product, but they don't know what design they need, just what design they want. Now of course it falls back on you if you give them what they want and it doesn't work well. - there are many ways to tackle the same problem, many of them work okay, some of them work well and look nice, some of them work well, look nice and are easy to manufacture and maintain. But it also has to be the solution they need and one where you can convince them they want it. Finding a good solution is a lot like finding the biggest common denominator of a large set of numbers. As someone who worked in design before I can say that the most work and stress for me was bringing the clients up to speed, so I can communicate to them about the designs on one level. That meant explaining to them why their primary-color-powerpoint-comic-sans-poster communicates things they do not intend communicated.

saghm 3y ago
I suspect that this sort of problem is present is a _lot_ of fields; it's not a programming problem or a design problem specifically, it's a human communication problem, and those can make just about anything more difficult.
- atoav 3y ago
  Exactly, just think about any construction site on earth where throughout the construction they realize that they actually need windows or electricity.

esskay 3y ago

I've just spent the last two days building out a system based on an API created by our clients internal dev team, only to have both the project manager and client throw in a massive curveball they knew about but neglected to mention - the API's been rewritten and replaced with a new one with a vastly different architecture. That's ~12 hours of work down the drain and one demoralized developer. It baffles me how this kind of thing continuously happens everywhere. Part of it seems to be that despite how many times you explain it to stakeholders, they don't seem to grasp that development takes time, and altering the plan mid way through is not only incredibly distracting but comes as a mental blow to the developer.

imetatroll 3y ago
I think it is more that they don't respect developer time.
- ghaff 3y ago
  Any project of any size with any degree of coordination ends up with considerable wasted motion and "do what I mean not what I literally said." Maybe this wouldn't happen in an ideal world. We don't live in an ideal world. Even rigorous efforts to specify requirements (e.g. waterfall) didn't work very well and it's pretty much the definition of iterative development of anything that you throw a lot of stuff out but hopefully not big chunks (which 12 hours is not). That would be spending a month of something to find you were on the wrong track.
  - saghm 3y ago
    I think the point is that nothing about this is really that specific to programming; what we're talking about here isn't an instance of programming being hard but effective communication being hard. The parts of software development that are time consuming aren't very intuitive to non-programmers because there isn't an obvious way to show tangible progress, which makes it very hard to track externally, so it relies more heavily on verbally communicating the current state of things, and that introduces the potential for a lot of misunderstandings.

Scarblac 3y ago

But all that is part of programming. It's not made harder than it needs to be, it is that hard. Because exploring the whole problem space with the stakeholders and deciding together what the software should do is a central part of the problem of programming. And it's ignored by everyone, the stakeholders don't realize it's a problem, the programmers know but think it's not their problem, and nobody includes it in estimates or plans the required time and meetings for it to happen.

dragonwriter 3y ago
> But all that is part of programming. Nah, its systems analysis, a field which is largely either forgotten (in the “cross-functional means everyone is a nobdifferentiated developer” school of Agile teams) or replaced with “business analysis”, whose practitioners have less relevant skills (particularly, systems analysts were experienced programmers with additional process engineering skills, while BAs are nonprogrammers in a role that is often structured more as stenography than engineering) and “software architects” (who have a closer skill set to systems analysts, but have a role with a simulta!eously more abstract and narrower, implementation-focused orientation.) Systems analysis requires (or at least benefits from) an understanding of programming, but its not the same skill
- arethuza 3y ago
  Good BAs that have domain specific knowledge are really valuable.
  - dragonwriter 3y ago
    Sure, my issue is with the culture and idea of what is needed that has driven the structure of the workforce and the way many orgs treat the role.
    - arethuza 3y ago
      Sorry - I was trying to agree with you :-)

sancarn 3y ago

I feel like communication of requirements is difficult too. I'm currently a business end-user, with developer experience, who is maintaining legacy VBA technology, trying to get an official system produced by a 3rd party contractor. The requirements started out truly quite simple - we want a database and a nodejs web server. But Technology are gate-keepers. We're not being trusted with what we want, or with that level of control over the system. Which then starts this cat chasing mouse thing of what the Technology will allow and what the business wants. I've always vouched for "Internal IT" - specialised developers who work closely with the team, even doing the jobs users do, to self-identify what technology is required and kickstart these projects. Edit: in this particular project, I handed over numerous diagrams of how the system should be architectured, and Technology BA's came back with a proposed set of technologies (SASS) that simply wouldn't be technically feasible... It's really made me lose hope.

c22 3y ago

I think there's something to this. When I write programs to solve my own problems I find the process easy and enjoyable.

sebastianz 3y ago
How big are the programs, how often do your requirements change, and how many years or decades do you develop and support them? Because tiny one time programs are indeed fun for a while until they “grow up”. :)
- c22 3y ago
  Small, rarely, and usually for one or more decades :)

Hermitian909 3y ago

This actually touches on one of SV's durable advantages in the software world: the realization that if you want good software your engineers must be involved in the requirements gathering, design, and scoping phases. Critically, the business understands that engineering is the most authoritative voice on cost and since all business activities should pass through an ROI analysis filter engineering needs to be in the room. Keeping engineers in the room then adds a positive feedback loop: as they understand the business better they start to offer up new opportunities to the business that have surprisingly low cost. (I will caveat that for sufficiently solved problems you can generally involve software engineers less)