> 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.

▲

mytailorisrich 5 days ago | parent | next [-]

> 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.

▲

stonemetal12 4 days ago | parent | next [-]

>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?

▲

mytailorisrich 4 days ago | parent [-]

> 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?

I think you mean "requirements" here instead of "design".

	▲	motorest 4 days ago \| parent [-]
		> I think you mean "requirements" here instead of "design". No. This is exactly what you are getting wrong. Requirements are constraints that guide the design. The design then is used to organize, structure, and allocate work, and determine what code needs to be written.

▲

motorest 5 days ago | parent | prev [-]

> 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.

▲

ndriscoll 4 days ago | parent | prev [-]

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.

▲

motorest 4 days ago | parent [-]

> 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.

	▲	ndriscoll 3 days ago \| parent [-]
		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.