6 ms·

> “The ones where people sound smart but aren't actually designing anything useful.” I’ve been part of lots of teams and teams composed of great and poor level

> “The ones where people sound smart but aren't actually designing anything useful.” I’ve been part of lots of teams and teams composed of great and poor levels of talent and I’ve never seen this type of behavior which you describe. Usually the folks getting up in arms over architecture are pissed because folks with experience shot down their idea for reasons of pragmatism and the individual couldn’t handle it because of ego.

milesvp 9y ago
You may have been lucky. One of the worst messes I had to make work was nonsense a senior dev was working on up until he quit. It was a mess of object oriented wankery that soured me to even the term 'object' for years. He needed to implement 6 funtions with a couple of sql statements to do session handling in php, and instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. He was supposed to be done, and it just needed deployment, but it ended up taking me 3 months, and a half dozen late night deployments and rollbacks before I managed to get it working. If I'd been more experienced at the time I would have ripped it all out and just implemented the 6 functions we needed, but I really assumed he'd had a good reason for the nonsense he'd written.
- itronitron 9y ago
  that reminds me of all the EJB/JBoss/Spring nonsense that soured Java for a lot of people... presumably it was a necessary step but it would have been nice to just skip ahead to web services
  - watwut 9y ago
    Web services are done with spring now.
    - itronitron 9y ago
      If anyone has written a review of the current state of the art with spring and web services I would be interested to read that.
- josephg 9y ago
  Years ago I was a TA for first year computer science. I graded my students' assignments on code style, with reference to automatic grades generated by a test suite. One of the most interesting things I learned was how much variance there was in code size between submissions. I would first read an assessment from a good student which was completely correct and 500 lines long. The code would seem reasonably clear, compact and well written. Then I'd pick up the next assignment, which had also gotten 100% on the automatic tests and it would be only 150 lines of code. And the code wouldn't seem any more compact or unreadable compared to the first - they both looked like decent solutions; but one of those solutions had implemented the same spec in 3x less code! And then I'd pick up a submission by a weaker student who got 50% of the automarking results done. The submission would be 600 lines, and you could see the sweat that had gone into writing it. The student was clearly struggling to keep track of all the moving parts in their code. If that was all I looked at I would have assumed the assignment would have taken 1000 lines to implement, and be way too hard for my first year students. (In case you're wondering, there was no difference in programming languages, tooling or knowledge. All students were using the same environments to write plain C code.) The lesson I learned was that its very hard to tell whether you or your coworkers are actually using a good approach to solving your problems. I never hear people say things like "Oh, I think this different abstraction could save us 70% of our code". But having seen enough examples I think its usually the case that those abstractions exist. We just (bizarrely) don't seem to spend any time looking for them. Intuitively I would expect that bad abstractions would be obvious in code, but that seems to be often not true in practice. After reading the first students' submission I usually would still have no idea how long the average correct submission was going to be.
  - watwut 9y ago
    It seem clear to me that both students described in second paragraph produced good code, although the shorter one was better. The second paragraph student was clearly behind them. It just does not seem hard. I heard colleagues say "if we split this away, join these two classes into one and hide it under interface, it will be simpler/shorter". The word abstraction was not used, but it was abstraction they were talking about. So maybe it depends on local culture, whether people talk about how things are done overall or whether they focus on idioms only. Edit: fixed typo in clearn/clear
- geezerjay 9y ago
  > instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. Factories: generate objects whose type can freely change. See polymorphism. Visitors: create any operation you'd like to implement without having to change a type. See open/close principle. Repositories: separate SQL voodoo from your code and establish a dedicated component to handle database transactions. Façade: isolate the world from all the gory detail in a manner that you are free to change both the component and its clients. See separation of concerns. I find it more worrying that the code developed by a senior developer was dumped just because the junior developer who replaced him was entirely clueless and not obly unable to understand existing codebut also unable to even grasp basic design problems that justify the senior developer's decision. Recommended reading: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
  - milesvp 9y ago
    I find it more troubling that someone would think they needed any of these patterns to implement php sessions. What you fail to grasp was the code was so completely unnecessarily complicated that it introduced a fuckton of subtle bugs that were difficult to track down. Things would look like they're working, and then reports of terribly broken behavior forcing an emergency rollback followed by days of trying to figure out what bullshit state things were in to repro the problem. Worse, is so much of the code was some misguided attempt to future proof the code in ways that make no sense. When your code will never have more than a couple dozen simple sql queries you will never benefit from a polymorphic sql class intended to allow the swapping out of your sql backend with another vendor. It's easier just to rewrite that small piece of code when the time comes. Just because you can implement fizzbuzz using a dozen design patterns doesn't mean the problem actually requires it.

milesvp 9y ago

You may have been lucky. One of the worst messes I had to make work was nonsense a senior dev was working on up until he quit. It was a mess of object oriented wankery that soured me to even the term 'object' for years. He needed to implement 6 funtions with a couple of sql statements to do session handling in php, and instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. He was supposed to be done, and it just needed deployment, but it ended up taking me 3 months, and a half dozen late night deployments and rollbacks before I managed to get it working. If I'd been more experienced at the time I would have ripped it all out and just implemented the 6 functions we needed, but I really assumed he'd had a good reason for the nonsense he'd written.

itronitron 9y ago
that reminds me of all the EJB/JBoss/Spring nonsense that soured Java for a lot of people... presumably it was a necessary step but it would have been nice to just skip ahead to web services
- watwut 9y ago
  Web services are done with spring now.
  - itronitron 9y ago
    If anyone has written a review of the current state of the art with spring and web services I would be interested to read that.
josephg 9y ago
Years ago I was a TA for first year computer science. I graded my students' assignments on code style, with reference to automatic grades generated by a test suite. One of the most interesting things I learned was how much variance there was in code size between submissions. I would first read an assessment from a good student which was completely correct and 500 lines long. The code would seem reasonably clear, compact and well written. Then I'd pick up the next assignment, which had also gotten 100% on the automatic tests and it would be only 150 lines of code. And the code wouldn't seem any more compact or unreadable compared to the first - they both looked like decent solutions; but one of those solutions had implemented the same spec in 3x less code! And then I'd pick up a submission by a weaker student who got 50% of the automarking results done. The submission would be 600 lines, and you could see the sweat that had gone into writing it. The student was clearly struggling to keep track of all the moving parts in their code. If that was all I looked at I would have assumed the assignment would have taken 1000 lines to implement, and be way too hard for my first year students. (In case you're wondering, there was no difference in programming languages, tooling or knowledge. All students were using the same environments to write plain C code.) The lesson I learned was that its very hard to tell whether you or your coworkers are actually using a good approach to solving your problems. I never hear people say things like "Oh, I think this different abstraction could save us 70% of our code". But having seen enough examples I think its usually the case that those abstractions exist. We just (bizarrely) don't seem to spend any time looking for them. Intuitively I would expect that bad abstractions would be obvious in code, but that seems to be often not true in practice. After reading the first students' submission I usually would still have no idea how long the average correct submission was going to be.
- watwut 9y ago
  It seem clear to me that both students described in second paragraph produced good code, although the shorter one was better. The second paragraph student was clearly behind them. It just does not seem hard. I heard colleagues say "if we split this away, join these two classes into one and hide it under interface, it will be simpler/shorter". The word abstraction was not used, but it was abstraction they were talking about. So maybe it depends on local culture, whether people talk about how things are done overall or whether they focus on idioms only. Edit: fixed typo in clearn/clear
geezerjay 9y ago
> instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. Factories: generate objects whose type can freely change. See polymorphism. Visitors: create any operation you'd like to implement without having to change a type. See open/close principle. Repositories: separate SQL voodoo from your code and establish a dedicated component to handle database transactions. Façade: isolate the world from all the gory detail in a manner that you are free to change both the component and its clients. See separation of concerns. I find it more worrying that the code developed by a senior developer was dumped just because the junior developer who replaced him was entirely clueless and not obly unable to understand existing codebut also unable to even grasp basic design problems that justify the senior developer's decision. Recommended reading: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
- milesvp 9y ago
  I find it more troubling that someone would think they needed any of these patterns to implement php sessions. What you fail to grasp was the code was so completely unnecessarily complicated that it introduced a fuckton of subtle bugs that were difficult to track down. Things would look like they're working, and then reports of terribly broken behavior forcing an emergency rollback followed by days of trying to figure out what bullshit state things were in to repro the problem. Worse, is so much of the code was some misguided attempt to future proof the code in ways that make no sense. When your code will never have more than a couple dozen simple sql queries you will never benefit from a polymorphic sql class intended to allow the swapping out of your sql backend with another vendor. It's easier just to rewrite that small piece of code when the time comes. Just because you can implement fizzbuzz using a dozen design patterns doesn't mean the problem actually requires it.