[onion2k]

That's the planning part.

Usually it's done as a collaboration between the systems architect and the QA team. The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do, and it relegates developers to a pretty minor role in the whole development process. They end up just filling in the blank bits in someone else's design. Most changes in team structure over the past couple of decades have been about developers taking on more of the responsibilities rather than less.

It's actually one of the aspects of TDD that makes it so robust. If you properly design your code and really think about its APIs you get a better app at the end. It does take longer to get something a user can see though, but often the process gets to a finished iteration of an app quicker because there's fewer cycles of debugging and fixing needed.

[realusername]

> The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do

That's a very charitable way to say it, on my case I would call this kind of process very convoluted and similar to early 2000s style development. I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards.

[onion2k]

I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards.

Everyone who works on the app is making those decisions no matter what you do. The difference is that in the "old style" the decisions were made before the code is written, and in the agile "new style" the decisions are made after the code is written. Often that's fine, because developers are generally good at their work and they make decent decisions, but sometimes they get it wrong and that's when code design issues arise. It's also what leads to automated tests failing to test for a lot of cases that a good QA engineer would have written tests for. Those things have an impact on the user.

A huge amount of the code in apps we use every day was never designed. No one thought it through. No one considered the edge cases. Features are thrown together in a week and 'sort of' work. Every time you see a shitty broken website, or a bug in production, or some crappy slow thing that should be fast the reason behind the problem is that the developers who made it didn't take the time (or even have the time in really bad companies) to think about what they were building. A lot of developers like that working environment because they can hack on things and move on to the next challenge quickly. That's fun. I argue it's also bad for users, and I care more about users than I care about developers (and I say that as a developer whose been making web stuff for almost 25 years.)

I'm not arguing that we go back to Prince2 and waterfall. There's a limit to my tolerance of bureaucracy too. I'm saying that things have gone a bit too far the other way, and many developers need to spend more time planning what code is written before leaping in and coding up the first solution they think will pass the acceptance criteria someone from product wrote.

[kubanczyk]

> I'm not arguing that we go back to Prince2 and waterfall.

Earlier you proposed: "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". This is precisely waterfall. Detaching the term from the emotions and bad PR, there are decades of real experience of people who did that and discussed their results.

The bureaucracy is not the cause. I argue the causality is: the "design first" assumption -> the "throw it over the fence" practice -> everyone blames everyone -> Prince2 comes to the rescue.

> I say that as a developer whose been making web stuff for almost 25 years.

> I'm saying that things have gone a bit too far the other way, and many developers need to spend more time planning...

Amen!

[chunkyfunky]

>This is precisely waterfall

I'm not sure I fully agree, unless we want to define waterfall as "anything where a bit of time is spent up-front to decide how a part of the system should work" :)

For me, waterfall is where every single aspect of the project is pre-defined, and cannot be changed during development without serious pain and lots of awful bureaucracy

But in the above workflow, there isn't anything stopping us from making a loop for example on a sprint by sprint basis, and using feedback from both the tests and changing requirements to improve the design, update the APIs, change the tests, etc.

I suppose we could argue that this is "mini-waterfall" but it works in my experience :)

[friendzis]

> I would call this kind of process very convoluted and similar to early 2000s style development

The 2000s style you are referring to was centered around "features" or "business cases". One unit of work = one feature. The bureaucracy is orthogonal.

Modern "agile" style is centered around "sprints". One unit of work = one sprint duration.

The bureaucracy inevitably involves synchronization points and enforces more or less linear process, which usually implies longer "real world" feedback loops. Lack of bureaucracy allows for concurrency and possibly shortens the feedback loop, which may be nice at first, but then you slowly informally incorporate the bureaucracy back - code owners, design sessions, etc..

The bureaucratic process is not inherently bad, the agile process is not inherently good. In some cases quick turnaround of basic features is more profitable, in other cases correctness may be most important. I can agree that quick feedback is more fun to work in, but it is not necessarily the best way.

[dataduck]

So how do you test the design? I ask this sincerely. To me it seems that it's rare to know in correct detail what the design is supposed to do in advance, but also that even if you do, it often has oversights that aren't spotted until you've built them.

[onion2k]

You still work in sprints and deliver features to the user regularly, and iterate to the right solution. I'm not suggesting you design all the code in the entire app and write all the necessary tests for every feature at the beginning; you still only design the bits that are needed right now. The development process just has a lot more upfront thought time, more upfront test writing time, and less coding time because if your code passes the tests you know it's correct (based on the assumptions about what 'correct' is right now.) There's always going to be a requirement to go back and improve things, pay down technical debt, fix design issues, etc no matter what your development approach is.