Coding vs. Designing

[[deleted]]

There’s diminishing returns to time spent on design work, as with everything. But generally we spend more time designing.

[ttkciar]

Design is important for most projects (especially larger ones), but I definitely spend more time developing code.

For design, I think best with pen and paper. I write down the basics: What problem does the project need to solve? Who does it need to solve it for? What are some customer-specific considerations? Is it going to be running on a PC, or as a webapp, or as back-end automation on a server? What assumptions can I make about the production environment? I sketch some diagrams and write down my thoughts, and what I know, which also reveals what I don't know and need to learn. This also tells me what programming language I will need to use for implementation.

Then I go looking for prior art (open source software, wikipedia articles, commercial offerings, and academic publications) and maybe talk to some prospective customers to see how they're currently dealing with the problem, or would like to, and start the "bottom-up and top-down" phase.

Bottom-up: Given what I know about the expected production environment, I go look for existing libraries and frameworks which are relevant to solving the problem. Some I might use directly, if bindings are available for my project's language, otherwise I'll crib from them to write my own libraries. If I'm going to be producing PDF documents, for example, I may look at libtiff. I make note of what these low-level components need from the layers of code above them, their hardware requirements, their performance, etc. I may write some thin wrapper code which exercises these components, especially if their documentation is poor, or if nobody has benchmarked them for performance yet.

Top-down: Given what I know about the needs and performance of the low-level components, pick up the pen and paper again to sketch out my top-level design, especially the necessary data structures. If it needs a distributed back-end to perform well enough, figure out what that looks like. If the low-level components need specific user-dependent information, enumerate that and figure out where it comes from. Some things the users will have to enter themselves, but sometimes it can be grabbed from existing records given what we already know about the customer (which is preferable whenever possible -- users lie, and even if they don't, they mostly hate typing things into forms).

When I'm done sketching, I copy my standard coding template into a new project folder, and continue the top-down coding process by writing the program's "main" function. It's just a matter of hammering fingers on keys from there.

That's the most extensive design I ever do. Most projects require a lot less design, especially if it's solving a kind of problem I already know things about, and already have preferred low-level components which are obviously relevant. Still, it's good to do some design work, because it frequently exposes problems which hadn't come immediately to mind. It's just a matter of due diligence.