Comment by motorest

It is, as often, a trade-off.

You need a high level design up-front but it should not be set in stone. Writing code and iterating is how you learn and get to a good, working design.

Heavy design specs up-front are a waste of time. Hence, the agile manifesto's "Working software over comprehensive documentation", unfortunately the key qualifier "comprehensive" is often lost along the way...

On the whole I agree that writing code is the design phase. Software dev. is design and test.

Reply View 9 replies

motorest 4 days ago

> You need a high level design up-front but it should not be cast in stone.
Yes, you need a design that precedes code.
> Writing code and iterating is how you learn and get to a good, working design.
You are confusing waterfall-y "big design upfront" with having a design.
It isn't.
This isn't even the case in hard engineering fields such as aerospace where prototypes are used to iterate over design.
In software engineering fields you start with a design and you implement it. As software is soft, you do not need to pay the cost of a big design upfront.

Reply View | 8 replies
- mytailorisrich 4 days ago
  
  > You are confusing waterfall-y "big design upfront" with having a design.
  I do not and I have explained it.
  > In software engineering fields you start with a design and you implement it
  And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked.
  > you do not need to pay the cost of a big design upfront
  Exactly, and not only that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code. So keep your design as a high-level initial architecture then quickly iterate by writing code to flesh out the design.
  Software is often opposed to "traditional engineering" but it is actually the same. How many experiments, prototyopes, iterations go into building a car or a rocket? Many. Engineers do not come up with the final design up front. The difference it is that this is expensive while in software we can iterate much more, much quicker, and for free to get to the final product.
  
  Reply View | 4 replies
  
  stonemetal12 3 days ago
  
  >How many experiments, prototyopes, iterations go into building a car or a rocket? Many. Engineers do not come up with the final design up front.
  No where did anyone claim you need the full final design up front. For cars\rockets how many of those experiments, prototypes, and iterations had designs? All of them. You never see a mechanical engineer walk out to the shop and just start hammering on a pile of slop until it sort of looks like a car.
  >The difference it is that this is expensive while in software we can iterate much more, much quicker, and for free to get to the final product.
  If you have no design to meet how do you judge the output of an iteration or know you have arrived at the final product?
  
  Reply View | 2 replies
  
  motorest 4 days ago
  
  > I do not and I have explained it.
  You should review the sources of your confusions and personal misconceptions, as you deny design and then proceed to admit there is design.
  > And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked.
  Nonsense. "Big design upfront" works, but is suboptimal in software development. That's why it's not used.
  "Big design upfront" approaches are costly as it requires know-how and expertise to pull off, which most teams lack, and it assumes requirements don't change, which is never the case.
  Once you acknowledge that requirements will change and new requirements will emerge, you start to think of strategies to accommodate them. In software development, unlike in any hard engineering field, the primary resource consumed is man-hours. This means that, unlike in hard engineering fields, a software development process can go through total rebuilds without jeopardizing their success. Therefore in software development there is less pressure to get every detail right at the start, and thus designs can be reviewed and implementations can be redone with minimal impact.
  > Exactly, and not only that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code.
  Yes.
  But you do need a design upfront, before code is written. Design means "know what you need to do". You need to have that in place to create tickets and allocate effort. It makes no sense at all to claim that writing code is the design stage. Only in amateur pet projects this is the case.
  
  Reply View | 0 replies
- ndriscoll 4 days ago
  
  The difference I see is that in other fields, part of your design process is thinking through the logical details of the thing. Essentially, doing some math. In software, the logical details are the finished product. The math is what you're trying to make. If you've actually thought through all of the details, you have written the software (if only in your head). If you haven't thought through all of the details and only figured out a high level design, you've still written some software (essentially, stubbing out some functionality, or leaving it as a dependency to be provided. However you want to think of it). So naturally, one way to think through things is to write software.
  
  Reply View | 2 replies
  
  motorest 3 days ago
  
  > The difference I see is that in other fields, part of your design process is thinking through the logical details of the thing. Essentially, doing some math.
  The "some math" is used in engineering fields in things like preliminary design, sizing, verification&validation, etc. To a lesser degree, "some math" can be used in the design stages of software development projects. For example, estimating the impact of micro services tax in total response times to verify if doing synchronous calls can work vs doing polling/messaging. Another example is estimating max throughput per service based on what data features in a response and how infrastructure is scaled. This is the kind of things that you do way before touching code to determine if the expected impact of going with a particular architecture vs another that mitigates issues.
  > In software, the logical details are the finished product. The math is what you're trying to make.
  You're confused. The design stage precedes writing any code, let alone the finished product. Any remotely complex work, specially if it involves architecture changes, is preceded by a design stage where alternatives are weighed and validated, and tradeoffs are evaluated.
  To further drive the point home, in professional settings you also have design reviews for things like security and data protection. Some companies even establish guidelines such as data classification processes and comparative design to facilitate these reviews.
  > If you've actually thought through all of the details, you have written the software (if only in your head). If you haven't thought through all of the details and only figured out a high level design, you've still written some software (essentially, stubbing out some functionality, or leaving it as a dependency to be provided. However you want to think of it).
  You're confusing having a design stage with having a big design upfront. This is wrong.
  The purpose of the design stage is to get the necessary and sufficient aspects right from the start, before resources are invested (and wasted) in producing something that meets requirements. No one cares what classes or indentation style you use to implement something. The ultimate goal is to ensure the thing is possible to deliver, what it actually does and how it does it, and if it is safe enough to use. You start writing code to fill in the details.
  
  Reply View | 1 reply
  
  ndriscoll 3 days ago
  
  Design reviews don't mean you don't write code first. We have a change that we're about to put through security review right now to special case TLS handling when talking to some older clients, but before we put a proposal forward, I validated that the core idea will actually work and that we can heavily restrict the scope of what the change applies to by writing the code and tests to do it. Meetings and asking multiple people to read through and provide feedback on documents very quickly racks up hours. Best to spend an hour or two first validating that what you're proposing isn't nonsense. This lets us be very specific about what the problem is, what the proposed solution is, and what the risks are.
  With data classification, you're going to need to think through what data you are using and what you want to do with it. i.e. write a program.
  I didn't claim class structure or indentation matters. I'm saying that assuming you are discussing some sort of algorithm or functionality, a formal language is a perfectly fine thing to use for thinking about the problem and writing down your ideas. Writing "what it actually does and how it does it" is just programming. If you write your ideas in a language like Scala, they can easily be more concise (so easier to review) than they would be in English, and you get a compiler helping you think through things.
  
  Reply View | 0 replies

ozim 3 days ago

Operation that uses software developers not as code monkeys but actual business problem solvers that have also business knowledge.

Operation that delivers features instead of burning budget on discussions.

Operation that uses test/acceptance environments where you deploy and validate the design so people actually see the outcome.

Obviously you have to write down the requirements - but writing down requirements is not design phase.

Design starts with idea, is written down to couple sentences or paragraphs then turned into code and while it is still on test/acceptance it still is design phase. Once feature goes to production in a release "design phase" is done, implementation and changes are part of design and finding out issues, limitations.

Reply View 0 replies

ownagefool 4 days ago

This response is rude / insulting and doesn't actually add much because you've just asserted a bunch of fallacious opinions without any meat.

My opinion is reality is more nuanced. Both "the code is self documenting" and "the code is the design" are reasonable takes within reasonable situations.

I'll give an example.

I work in a bureaucratic organization where there's a requirement to share data and a design doc that goes through a series of not-really-technical approvals. The entire point of the process is to be consumable to people who don't really know what an API is. It's an entirely reasonable point of view that we should just create the swagger doc and publish that for approval.

I worked in another organization where everything was an RFC. You make a proposal, all the tech leads don't really understand the problem space, and you have no experience doing the thing, so you get the nod to go ahead. You now have a standard that struggles against reality, and is difficult to change because it has broad acceptance.

I'm not saying we should live in a world with zero non-code artifacts, but as someone who hops org to org, most of the artifacts aren't useful, but a CI/CD that builds, tests, and deploys, looking at the output and looking at the code gives me way more insight that most non-code processes.

Reply View 0 replies