4 ms·

> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s

> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requirements or application states. Yes, planning reduces bugs, but bugs are still inevitable no matter what software design process we use.

extrapickles 8y ago
I agree with you. Issues with communication were directly attributable to ~1/3 of the bugs in software I've worked on. These bugs are unfixable with any process as they are caused by not stating a requirement/feature/bug in a way that is understood perfectly by the developer writing the code.
krona 8y ago
Yes, you can't prove a negative. I'm pretty sure it was a joke.
- deleted 8y ago
  [deleted]
hinkley 8y ago
The experience of fixing a bug somewhere in a Ball of Mud is profoundly different than fixing it in better factored code.
codeflo 8y ago
> I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requirements or application states. In my experience, that's only true code that's relatively well-engineered to begin with. Unfortunately, there are lots of bugs in real-world shipping software that have nothing to do with an unforeseeable environment, but are only the result of unnecessarily complex designs that even the original programmer hadn't completely thought through. So while good design might not eliminate bugs, bad (or no) design can definitely create them.
codemac 8y ago
Cleanroom has a lot of evidence that process (especially around code inspection/review) does improve quality more than TDD or other methods of detailed design, most people are just unwilling to take the time for detailed process for quality IMO.
- crdoconnor 8y ago
  That's frequently a reasonable trade off. A lot of businesses need a proof of concept to test product market fit. IMHO TDD can often be a massive waste of time if that is the case. There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch.
  - codemac 8y ago
    > There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch. Cleanroom is actually completely reasonable for this - what you must accept is that transforming a rushed proof concept into a production quality application is starting from scratch in terms of ascii in github. It's the experience of those that worked on it that is valuable to save.
wsy 8y ago
You need to get your domain concepts right, and to let your code reflect these concepts. Then, fewer bugs occur because mapping a business request to code becomes a simpler task. Also, it becomes easier to understand and fix bugs, because again the mental mapping from customer-observable behavior to code is easier. Still, I agree with the advice to not introduce these abstractions early, because you will get them wrong.

extrapickles 8y ago

I agree with you. Issues with communication were directly attributable to ~1/3 of the bugs in software I've worked on. These bugs are unfixable with any process as they are caused by not stating a requirement/feature/bug in a way that is understood perfectly by the developer writing the code.

krona 8y ago

Yes, you can't prove a negative. I'm pretty sure it was a joke.

deleted 8y ago
[deleted]

hinkley 8y ago

The experience of fixing a bug somewhere in a Ball of Mud is profoundly different than fixing it in better factored code.

codeflo 8y ago

> I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requirements or application states. In my experience, that's only true code that's relatively well-engineered to begin with. Unfortunately, there are lots of bugs in real-world shipping software that have nothing to do with an unforeseeable environment, but are only the result of unnecessarily complex designs that even the original programmer hadn't completely thought through. So while good design might not eliminate bugs, bad (or no) design can definitely create them.

codemac 8y ago

Cleanroom has a lot of evidence that process (especially around code inspection/review) does improve quality more than TDD or other methods of detailed design, most people are just unwilling to take the time for detailed process for quality IMO.

crdoconnor 8y ago
That's frequently a reasonable trade off. A lot of businesses need a proof of concept to test product market fit. IMHO TDD can often be a massive waste of time if that is the case. There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch.
- codemac 8y ago
  > There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch. Cleanroom is actually completely reasonable for this - what you must accept is that transforming a rushed proof concept into a production quality application is starting from scratch in terms of ascii in github. It's the experience of those that worked on it that is valuable to save.

wsy 8y ago

You need to get your domain concepts right, and to let your code reflect these concepts. Then, fewer bugs occur because mapping a business request to code becomes a simpler task. Also, it becomes easier to understand and fix bugs, because again the mental mapping from customer-observable behavior to code is easier. Still, I agree with the advice to not introduce these abstractions early, because you will get them wrong.