In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.

I am literally in the middle of swapping DynamoDB for a RDBMS.

The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.

While he advocates for it, that’s also a point that Martin brings up multiple times when he talks about his project “fitnesse”.

Basically saying that they left it open how stuff can be saved, but the need has never arisen to actually pivot to a different system.

Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.

The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.

That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.

Interesting, thanks, I didn’t know anything about that. I’ve probably looked at the book at some point, but don’t remember anything about it.

So… What is the problem of women in tech? Either I skimmed over this or he fails to get to that point at all.

This is just a lot about people’s reactions to something, but nothing about what that something actually was

It’d be nice to see what the actual something was so one could judge for themselves

Edit: I took a look at his twitter, and he seems to be pro-trump and anti-kamala and anti-walz, calling him a socialist who let Minneapolis burn, as well as transphobia thrown in here and there and more that I didn’t bother to read

…so I’m gonna go with “the people’s reactions to him likely had a point”

A true man of the 70s-80s…

hearsay

I think its less about not understanding and more that these concepts only work in unrealistic scenarios that aren’t real. It’s the same with Agile. They never address the actual issue and try to work around them which never works.

The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.

Also while I used the more clean code oriented XML DOM implementation for my D XML parser (or at least copied such code as it was abandoned by its original creator), I planned a much simpler system for my SDLang parser. While everything originates from the DLElement abstract class, I didn’t go overboard with the interfaces, etc.

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of. The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development

They may be a part of software development, but they should not be common during the normal execution of software. I once read the hint, “if your app doesn’t run with all exception handlers removed, you are using exceptions in non-exceptional cases”.

Throwing an exception is a way to tell your calling function that you encountered a program state in which you do not know how to proceed safely. If your functions regularly throw errors at you, you didn’t follow their contract and (for instance) didn’t sanitize the data appropriately.

Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

I disagree here. You can always ignore an error return value and pretend that the “actual” value you got is correct. Ignoring an exception, on the other hand, requires the effort to first catch it and then write an empty error handler. Also (taking go as an inspiration), I (personally) find this very hard to read:

res, error = try_something()
if error {
  handle_the_error(error)
  return_own_error()
}
res2, error2 = try_something_else(res)
if error2 {
  handle_other_error(error2)
  return_own_error()
}
res3, error3 = try_yet_something_else(res2)
if error3 {
  handle_the_third_error(error3)
  return_own_error()
}
return res3

This code mingles two separate things: The “normal” flow of the program, which is supposed to facilitate a business case, and error handling.

In this example, on the other hand, you can easily figure out the flow of data and how it relates to the function’s purpose and ignore possible errors. Or you can concentrate on the error handling, if you so choose. But you don’t have to do both simultaneously:

try {
  res = try_something()
  res2 = try_something_else(res)
  res3 = try_yet_something_else(res2)
  return res3
} catch (e) {
  // check which error it is and handle it appropriately
  throw_own_exception()
}

I generally agree, but there are some things that are oversimplified. Sure a point(x, y) can have public attributes, but usually business objects are a bit more complex: insurancePolicy, deliveryRoute, user, etc. Having some control over those is definitely something you want to implement, at the cost of some boilerplate.

Functions should be small and do one thing […] you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together

I believe you have a wrong idea of what “one thing” is. This comes together with “functions should not mix levels of abstraction” (cited from the first blog entry you referenced). In a very low-level library, “one thing” may be sending an IP packet over a network interface. Higher up, “one thing” may be establishing a database connection. Even higher up, “one thing” may be querying a list of users from the database, and higher up yet again is responding to the GET /users http request. All of these functions do ‘one thing’, but they rely on calls to a few methods that are further down on the abstraction scheme.

By allowing each function to do ‘one thing’, you decompose the huge problem that responding to an HTTP request actually is into more manageable chunks. When you figure out what a function does, it’s way easier to see that the function connectToDb will not be responsible for why all users are suddenly called "Bob". You’ll look into the http handler first, and if that’s not responsible, into getUsersFromDb, and then check what sendQuery does. If all methods truly do one thing, you’ll be certain that checkAuthorization will not be related to the problem.

Tell me if I just didn’t get the point you were trying to make.

Edit: I just read

Martin says that functions should not be large enough to hold nested control structures (conditionals and loops); equivalently, they should not be indented to more than two levels. He says blocks should be one line long, consisting probably of a single function call. […] Most bizarrely, Martin asserts that an ideal function is two to four lines of code long.

If that’s the standard of “doing one thing”, then I agree with you. This is stupid.

Thank you for linking the blog posts. They are a really good deterrent from Clean Code. I once thought I’d read it, but Fowler’s advice really is stupid.

In case you’re wondering why I replied three times: “Do one thing” :)

During the George Floyd Protests, Robert gives us a beautiful take that police stopping black people isn’t racist, it’s just math.