3 ms·

Developer for 20+ years. I can't even design anything without coding something.

jillesvangurp 2y ago
Exactly. I did a Ph.D. on software engineering and architecture before embarking on a career practicing what I preach. One thing that I realized early is that designs always lag implementations. They are aspirational at best. And people largely stopped using design tools completely when agile became a thing. Some still do. But you'll look in vain for UML diagrams on most software you ever heard off. I now have a few decades of experience doing technical work, running startups, teams, doing consultancy, etc. Coding is my way of getting hands on. It's quicker for me to just prototype something quickly in code than it is to do whatever on a whiteboard. I always run out of space on whiteboards and they don't have multi level undo, auto completion, etc. They really suck actually. I avoid using them. Of course, I sometimes chin stroke extensively before coding; or I restart what I'm doing several times. But once I have an idea of what I'm doing in my head, I stub out a solution and start iteratively refining. And if I'm stuck with the chin stroking, the best way to break through that is to just start coding. Usually, I then discover things I hadn't thought about and realize I don't need to over complicate things quite as much. This progressive insight is something you can only gain through doing the work. The finished code is also the finished design; they co-evolve and don't exist as separate artifacts. The engineering fallacy is believing that they are separate and that developers are just being lazy by not having designs. Here's a counter argument to that: we don't build bridges, rockets, expensive machines, etc. Our designs compile to executable code. Physical things have extensive post design project phases where stuff gets built/constructed/assembled. Changing the design at that stage is really expensive. For software, this phase is pretty much 100% automated in software. And continuous deployment means having working stuff from pretty much as soon as your builds start passing. Of course refactoring your design/code still is important. You risk making it hard to evolve your software otherwise. The process of designing a bridge is actually more similar to developing software than the process of constructing one. The difference is that when you are done with the bridge design, you still have to build it. But it's a lengthy/risky process with progressive insights about constraints, physics, legislation, requirements, etc. Like software, it's hard to plan the design. And actually modern day architects use a lot of software tools to try out their designs before they hand them over. Just some simple insights here. There is no blue print for the blue print for either bridges or software. Not a thing, generally.
declan_roberts 2y ago
It's like giving an estimate for a bathroom remodel for a house you've never seen. You gotta get in there first.
- mexicocitinluez 2y ago
  I'd go one further and say it's an estimate for a bathroom remodel in a house you've never seen that turned out to actually be a garage remodel instead.
kstrauser 2y ago
I've compared it to finding the integral of a function. Unless it's trivial or closely resembles something I've done before, how am I going to have the faintest idea what it's going to be like until I start? Sometimes the exploration is the design process.
dsego 2y ago
You could try writing an RFC or a tech spec sometimes with different approaches, proposed solutions, pros/cons. It's basically coding and designing the system in your mind and anticipating issues and challenges. It's a good exercise to do this before writing a line of code. The more you do it, the easier it gets, the mind starts to think about different approaches and pitfalls, you get into a focused state where the brain organizes the logical flow and then you can write a rough outline without caring about making the compiler happy or what the exact syntax is. Sometimes it also helps to translate this high level outline into pseudocde in a comment and then fill in the blanks with actual code.

Exactly. I did a Ph.D. on software engineering and architecture before embarking on a career practicing what I preach. One thing that I realized early is that designs always lag implementations. They are aspirational at best. And people largely stopped using design tools completely when agile became a thing. Some still do. But you'll look in vain for UML diagrams on most software you ever heard off. I now have a few decades of experience doing technical work, running startups, teams, doing consultancy, etc. Coding is my way of getting hands on. It's quicker for me to just prototype something quickly in code than it is to do whatever on a whiteboard. I always run out of space on whiteboards and they don't have multi level undo, auto completion, etc. They really suck actually. I avoid using them. Of course, I sometimes chin stroke extensively before coding; or I restart what I'm doing several times. But once I have an idea of what I'm doing in my head, I stub out a solution and start iteratively refining. And if I'm stuck with the chin stroking, the best way to break through that is to just start coding. Usually, I then discover things I hadn't thought about and realize I don't need to over complicate things quite as much. This progressive insight is something you can only gain through doing the work. The finished code is also the finished design; they co-evolve and don't exist as separate artifacts. The engineering fallacy is believing that they are separate and that developers are just being lazy by not having designs. Here's a counter argument to that: we don't build bridges, rockets, expensive machines, etc. Our designs compile to executable code. Physical things have extensive post design project phases where stuff gets built/constructed/assembled. Changing the design at that stage is really expensive. For software, this phase is pretty much 100% automated in software. And continuous deployment means having working stuff from pretty much as soon as your builds start passing. Of course refactoring your design/code still is important. You risk making it hard to evolve your software otherwise. The process of designing a bridge is actually more similar to developing software than the process of constructing one. The difference is that when you are done with the bridge design, you still have to build it. But it's a lengthy/risky process with progressive insights about constraints, physics, legislation, requirements, etc. Like software, it's hard to plan the design. And actually modern day architects use a lot of software tools to try out their designs before they hand them over. Just some simple insights here. There is no blue print for the blue print for either bridges or software. Not a thing, generally.

declan_roberts 2y ago

It's like giving an estimate for a bathroom remodel for a house you've never seen. You gotta get in there first.

mexicocitinluez 2y ago
I'd go one further and say it's an estimate for a bathroom remodel in a house you've never seen that turned out to actually be a garage remodel instead.

kstrauser 2y ago

I've compared it to finding the integral of a function. Unless it's trivial or closely resembles something I've done before, how am I going to have the faintest idea what it's going to be like until I start? Sometimes the exploration is the design process.

dsego 2y ago

You could try writing an RFC or a tech spec sometimes with different approaches, proposed solutions, pros/cons. It's basically coding and designing the system in your mind and anticipating issues and challenges. It's a good exercise to do this before writing a line of code. The more you do it, the easier it gets, the mind starts to think about different approaches and pitfalls, you get into a focused state where the brain organizes the logical flow and then you can write a rough outline without caring about making the compiler happy or what the exact syntax is. Sometimes it also helps to translate this high level outline into pseudocde in a comment and then fill in the blanks with actual code.