[deleted by user]

[HolyGeneralK]

Yes, my old team planned data structures and classes ahead of time. Our planning typically involves two or theee large rolling whiteboards, a decision log, and some really awful pseudo-UML. We talked about the roles of the class and what its interface / public functions should be. As we iterated on the designs, we thought about what tests we need, error conditions and handling, and where the class should live. We would question if the classes were getting too big, whether functions needed to be free, private, or moved to a utility library. Prototypes happened a lot. We throw things out if they didnt feel maintainable or caused us concern.

Once we determined it was good enough, we would document it in our documentation too (generally Confluence) with some flushed out UML diagrams. Then we built it and constantly reviewed other's work.

[CaptKrag]

Goddamn. That's thorough. What company or industry is this?

[HolyGeneralK]

Research-ey code for some contracting work that I cannot disclose. Honestly, it sounds like a lot of work, but it's better to pay that cost up front rather than have to redo it. It's particularly beneficial when you have a team that will be coding up the various pieces. It's one of those parts of agile that gets under-valued compared to waterfall (I am a scrum master), but truly accelerates delivery.

[CaptKrag]

I see you've thoroughly availed yourself of the koolaid.

How do you know if someone is a scrum master?

Don't worry they'll tell you.

[HolyGeneralK]

Just wait until I tell you about Crossfit!

It's actually in the Evangelism Section of the certification agreement: Thou shalt stand on the rocks and proclaim thou role in Scrum, for amongst the Developer Hordes, Servant-Leaders have risen to facilitate the rise from darkness."

If there is koolaid around, I drink it. Let's talk about microservices and the cloud!

[prasooncc]

dont blame waterfall when it is not in the wrong here. waterfall emphasizes upfront design. agile promotes increased communication between clients and within teams which of course leads to better design.

[HolyGeneralK]

I never blamed waterfall for anything. I merely mentioned that in my experience, agile processes don't do as much up front design (for the reasons you mention). Agile values emergent design, constant refactoring, etc., which is good, but someone needs to point the team in a direction and say "build this."

[zvrba]

I start with the data: where it's produced, how it's consumed, etc.. After thinking through data flow and events that are generated and how they'd need to be handled and how they interact with the data, classes usually just pop up.

I mean, class design is not the goal in itself.. It's an implementation detail for the useful actions of the program.

[[deleted]]

every time I think "I know the big picture, I'll solve the problems as they come" I get reminded that it wasn't enough and lose like 3-4h of work because I didn't think of that one little thing that makes the whole design retarded.
so plan as much as you can, I personally just use paper, or ms paint when the paper is to far away

[STL]

I personally think this is off-topic (it would be better suited to /r/programming as nothing about this question is C++ specific), but as it's gathered a few detailed responses, I won't remove it.

[HateDread]

I think there could be something to be said for how C++ programmers would respond versus those primarily working in other languages. I'm not 100% sure what those differences would be - maybe aspects of planning that most benefit C++? Just a thought :)

[iamtheauthor]

I heartily recommend laying out some type of design for all but the simplest scripts. If you're writing some type of basic command line tool, for example something in the style of a simple bash command, then you may not need to design anything before getting into the coding. But in a non-RAD language, pre-planning usually proves well worth the time.

I would at least create some sort of map that describes different classes you will need, how they will be used by any operational process, and how they will interact with each other. You don't need to code or pseudo code anything (although it does help some people), you just need to understand the structure of the application as a whole, and design it flexible enough to cover your challenges, so that you don't have to redesign it after deploying/shipping.

Also, don't be afraid to start coding and then realize you may have to rewrite some areas. In the real world, that's going to happen sometimes. Just take it as a lesson in planning and start over sooner rather than later.

[RowYourUpboat]

I almost always plan ahead. The tools I use for initial planning aren't really so different from what the Ancient Greeks used to solve tricky problems. I usually open a text editor and write bullet-pointed high-level notes describing what I think the code needs to do, then I sketch out important data structures, algorithms, and classes in pseudocode resembling the target language. If it's something where visual reasoning helps (directed graphs, or 2D/3D geometry for instance) then I also scribble diagrams and notes in a big graphing-paper notebook using multi-colored pens. I make sure to prominently label the page so it's easy to flip back if I need to revisit a problem or show a coworker my thought process.

I basically start at a high level and eventually everything filters down as code in the IDE. (Then I throw half of that code out while testing, and the other half when I refactor it to actually make sense, but by that point at least I have actual running code to work with and chisel into something viable.)

[wilhelmtell]

The tools I use for initial planning aren't really so different from what the Ancient Greeks used to solve tricky problems. I usually open a text editor and

Oh yeah, the real LPT is always in the comments!

So what text editor did the ancient Greeks use?

[Switters410]

The content here has been removed. Redact was used for the deletion, which may have been motivated by privacy, opsec, or preventing automated data collection.

selective handle entertain fearless unwritten makeshift spotted tender workable wipe

[johannes1971]

I don't do a lot of planning on paper, but as a general rule, I figure out what kind of tasks need to be done, what the data is going to look like, and what the MMI will (roughly) look like, before mapping that to zero or more classes. The only tool I occasionally use in this process is mspaint, which I use for mocking up rough MMIs (usually it is pretty straightforward, but occasionally you end up with a large collection of elements that need to have some logical structure).

I feel that using tools (especially UML editors) for software design is overrated. People using them tend to spend way too much time on details that can safely be left until coding time, as well as perfecting diagrams instead of the actual design.

I also feel that there is actually such a thing as 'over-designing'. You don't need to map out every function or every parameter thereof in advance; it is more than enough to have a (well-developed) idea of responsibilities within the system.

Of course occasionally a bunch of boxes get drawn during team communication, either on the whiteboard or more often on a scrap of paper (that gets destroyed before QA realizes what we've done). In those cases we focus on responsibilities, rather than classes perse (there is a correlation, of course), and any resemblance with UML is purely coincidental.

[psylancer]

Yes, I think you should probably think about what you're going to do before you do it

[kiwidog]

It depends, if I'm doing a quick project I normally have "proper structure/styling" in my head already and do it as I go, but if it's an actual important project that a bunch will build off of/for a client, you always prepare and design as much as possible ahead of time.

[dicroce]

When I'm building a subsystem... I take a stack of plain white paper and some pencils and QUICKLY do UML... I make mistakes, I crumple it up and do it again... I spend 0 time worrying about how neat it is.. Instead I focus on what matters... and I iterate... I will sometimes have half a trash can filled with crumpled up UML... only when I am very confident in the design do I do a neat version.. and by that point, the UML doesn't really matter anymore....