4 ms·

The stereotype isn't that the code was bad -- it's around the UI. (There are also stereotypes around modern UI being too minimalistic. Obviously these things ar

The stereotype isn't that the code was bad -- it's around the UI. (There are also stereotypes around modern UI being too minimalistic. Obviously these things are not so simple.) There's also the idea NOT that it was bad when it was written 30 years ago, but that 30 years of patches by people who didn't write the original code mean it's no longer clean code.

WrtCdEvrydy 8y ago
Build the UI for the target user. Minimalistic UIs are great if you're trying to make it simpler for outsiders. If you have people who understand how to use the software, you can actually cram the UI full of everything you need in a single place.
- maxxxxx 8y ago
  Most UIs these days seem written for beginners. Easy to get in but they become tedious for experienced people.
  - sli 8y ago
    Oof. Currently developing software for doctors to use and this feels all too real. The concessions we have to make to cater to their relative inability to adapt would make me hate using this UI every day, but it's what they want. It's not like I don't get it. I do. Just not 100% of the time.
- jklinger410 8y ago
  Look, this sounds like you are talking about brutalist design for corporate software, and I can dig that. What I can not dig is how old software prints things to screen. Touch a new dimension, let's recompile the data and re-load the list/entire screen right now! We've never done analytics our study our user base, so the most popular functions are buried 10 levels deep in a menu that re-loads every time you lose your scroll spot! ETC. If you have spent time in corporate software developed in the WIN 95 days (cough oracle CRM cough) you won't see intentionally brutalist design. You will often see Magyver level hacks stacked through the roof, and software that loads so slowly you can re-load Gmail 3 times before it finishes.
  - maxxxxx 8y ago
    “you can re-load Gmail 3 times before it finishes.” After the latest changea to Gmail I have high hopes that it soon will catch up in terms of slowness :)
  - ams6110 8y ago
    First generations of browser-based UI did refresh/reload the page a lot. But there was nothing else they could do, really. AJAX wasn't a thing, DOM manipulation wasn't possible. Older UIs written in Visual Basic, Delphi, Powerbuilder, or even for text-mode interfaces did not do this, because the frameworks supported refreshing only the changed data. Look at how emacs or vi works over a 1200 baud dial-up connection. Surprise, it does, because it only redraws the parts of the screen that are changed. These problems were solved in the 1970s and 1980s. The web broswer has been for most of its existence a really bad way to deliver user interfaces. The zero-deploy nature of it was very powerful though, so people suffered through it. Only in the last few years have browser-based interfaces approached the abilities of native clients.
- basch 8y ago
  eg Facebook or Amazon or Outlook or Photoshop. The antithesis of minimalism, features and buttons everywhere.
thisisit 8y ago
Early in my career I worked on legacy i-Series systems. One of things we were taught was to never write a code without putting in comments in the header. And the commends need to specify dates, ticket number for tracking, and the rationale behind the change. Every changed line had to be inside a block with the same ticket number, making it easier to simply Ctrl+F through the code. Now I work on newer software and I frequently see people making changes without spelling out the rationale, dates, author etc. And it makes it harder to track what has happened and what does the code do exactly. When I tell people to comment it correctly they often reply about - how much time saving can be had by writing a clean code.
- deleted 8y ago
  [deleted]
- fwip 8y ago
  Nowadays we keep that information in the VCS. git blame gives you more reliable info than careful comments (assuming that the rationale is recorded in the commit message).
  - lostcolony 8y ago
    Integrate with a ticketing system, force commits to match a pattern, and you can ensure the rationale is tied to your ticketing system (i.e., commits/merges have to be prefaced with FOO-####)
    - maxxxxx 8y ago
      Obviously this system will be obsolete in a few years too and nobody will know how to find stuff int it :-)
    - pcnix 8y ago
      This happens on github/gitlab too, with pretty much all open source projects. It's definitely a cause for concern eventually, because the context for the problem and the rationale for decisions is now something that you have to maintain apart from just maintaining the codebase. Right now github etc do a good job of managing that for you, but the long term handling of this context definitely has scope to improve.

WrtCdEvrydy 8y ago

Build the UI for the target user. Minimalistic UIs are great if you're trying to make it simpler for outsiders. If you have people who understand how to use the software, you can actually cram the UI full of everything you need in a single place.

maxxxxx 8y ago
Most UIs these days seem written for beginners. Easy to get in but they become tedious for experienced people.
- sli 8y ago
  Oof. Currently developing software for doctors to use and this feels all too real. The concessions we have to make to cater to their relative inability to adapt would make me hate using this UI every day, but it's what they want. It's not like I don't get it. I do. Just not 100% of the time.
jklinger410 8y ago
Look, this sounds like you are talking about brutalist design for corporate software, and I can dig that. What I can not dig is how old software prints things to screen. Touch a new dimension, let's recompile the data and re-load the list/entire screen right now! We've never done analytics our study our user base, so the most popular functions are buried 10 levels deep in a menu that re-loads every time you lose your scroll spot! ETC. If you have spent time in corporate software developed in the WIN 95 days (cough oracle CRM cough) you won't see intentionally brutalist design. You will often see Magyver level hacks stacked through the roof, and software that loads so slowly you can re-load Gmail 3 times before it finishes.
- maxxxxx 8y ago
  “you can re-load Gmail 3 times before it finishes.” After the latest changea to Gmail I have high hopes that it soon will catch up in terms of slowness :)
- ams6110 8y ago
  First generations of browser-based UI did refresh/reload the page a lot. But there was nothing else they could do, really. AJAX wasn't a thing, DOM manipulation wasn't possible. Older UIs written in Visual Basic, Delphi, Powerbuilder, or even for text-mode interfaces did not do this, because the frameworks supported refreshing only the changed data. Look at how emacs or vi works over a 1200 baud dial-up connection. Surprise, it does, because it only redraws the parts of the screen that are changed. These problems were solved in the 1970s and 1980s. The web broswer has been for most of its existence a really bad way to deliver user interfaces. The zero-deploy nature of it was very powerful though, so people suffered through it. Only in the last few years have browser-based interfaces approached the abilities of native clients.
basch 8y ago
eg Facebook or Amazon or Outlook or Photoshop. The antithesis of minimalism, features and buttons everywhere.

thisisit 8y ago

Early in my career I worked on legacy i-Series systems. One of things we were taught was to never write a code without putting in comments in the header. And the commends need to specify dates, ticket number for tracking, and the rationale behind the change. Every changed line had to be inside a block with the same ticket number, making it easier to simply Ctrl+F through the code. Now I work on newer software and I frequently see people making changes without spelling out the rationale, dates, author etc. And it makes it harder to track what has happened and what does the code do exactly. When I tell people to comment it correctly they often reply about - how much time saving can be had by writing a clean code.

deleted 8y ago
[deleted]
fwip 8y ago
Nowadays we keep that information in the VCS. git blame gives you more reliable info than careful comments (assuming that the rationale is recorded in the commit message).
- lostcolony 8y ago
  Integrate with a ticketing system, force commits to match a pattern, and you can ensure the rationale is tied to your ticketing system (i.e., commits/merges have to be prefaced with FOO-####)
  - maxxxxx 8y ago
    Obviously this system will be obsolete in a few years too and nobody will know how to find stuff int it :-)
  - pcnix 8y ago
    This happens on github/gitlab too, with pretty much all open source projects. It's definitely a cause for concern eventually, because the context for the problem and the rationale for decisions is now something that you have to maintain apart from just maintaining the codebase. Right now github etc do a good job of managing that for you, but the long term handling of this context definitely has scope to improve.