6 ms·

I would like to know! I can go back 22 years. Then, jobs were more likely to be apps running on Windows. People yelling at screen because things aren’t renderin

I would like to know! I can go back 22 years. Then, jobs were more likely to be apps running on Windows. People yelling at screen because things aren’t rendering properly (render as in pixels, not virtual doms!). No unit tests. Sourcesafe (old buggy but simple to use VCS). You could exclusively lock a file to annoy other developers and stamp the importance of your work. No scrum and much less process. 9-5 ish and no time tracking. No OKR or KPI. Do everything with Microsoft tooling. No open source tooling. Someone’s job to build an installer and get it burned to a CD (the optical storage medium). There was some automated testing but no unit test or CI/CD. Not so many “perks” like swazzy office, toys, food supplies etc. If there was webdev it would be in ASP or ActiveX!

DamonHD 4y ago
I agree with a lot of that - I had to 'invent' unit tests for one of my clients for example for their production code. I managed to swerve MS tooling much of the time, one way or another. For example, I worked a lot with Sun workstations SunOS/Solaris.
- quickthrower2 4y ago
  Thats nice. I think MS programming stacks were most popular in the UK outside of universities (universities would also have Unix, Oracle DB and SunOS). I guess in California it would more likely skew Unix/Sun?
  - DamonHD 4y ago
    I (a) ran a very early Internet provider and then worked in (b) oil and (c) finance where good networking, speed and reliability were enough to make *nix a sensible choice. Though (for example) the finance world tried to move to MS to save money, and indeed I got paid a lot to port and maintain and optimise code across platforms including MS, the TCO thing would keep biting them...
Traubenfuchs 4y ago
I had all of this 11 years ago and it was BLISS. Oh MS source safe and it's locked files! No merge conflicts or rebasing clownery, ever! It forced two people working on the same code to sync and this avoided so many conflicts. Customers called with small bug reports, I could fix them in 5 minutes and deploy to production right from eclipse. Modern agile development is hell.
- fragmede 4y ago
  Nothing's stopping you from implementing file locking on a social level! "Hey I'm gonna be working in the foo/ subdir this week, mind staying out of there till next week?"
- robertlagrant 4y ago
  Random agile comment at the end of a comment on source control.
NayamAmarshe 4y ago
That makes me wonder, without all the unit tests and all the 'necessary' things we do to our codebase, did any of it really help? Are modern codebases with modern practices less buggy than the ones from 20 years ago?
- hinata08 4y ago
  In 1988, Airbus delivered the first A320 with electronic flight commands, which was safe. In 1998, the RATP inaugurated line 14 of the metro in Paris, which was fully automated, after formally proving that its software would never ever be able to bug. Gitlab didn't exist back then, and yet these companies made a code that was safe. I guess the main driver of code quality is whether the company cares, and has the proper specifications, engineering before coding, and quality management procedures, before the tech tooling. It certainly is simpler now to make quality code. But don't forget that software used to be safe, and it was a choice of companies like Microsoft, with Windows, or more recently Boeing with the 737 Max, to let the users beta test code and patch it afterwards (Aka early, reckless agile) So yeah, modern codes look less buggy. But it's mainly because companies care IMO.
  - PaulDavisThe1st 4y ago
    > I guess the main driver of code quality is ... picking a task for which can be implemented using the sort of processes you describe. Lots of things cannot be.
    - hinata08 4y ago
      Quality assurance and software engineering can be applied everywhere, no matter the processes you use to create and deliver the code. Methods and tools would be different, depending on context, but ANY serious company ought to do quality management At the very least, know your code, think a few moves ahead, make sure you deliver a safe code, and apply some amount of ISO9001 at the company level (and hopefully much more at any other level) Also, a security analysis is mandatory for both industrial code and for IT applications, thanks to standards, laws like the GDPR its principle of privacy by design, and contractual requirements from serious partners. You risk a lot if your code leaks customer data or crashes a plane. it's the same for having 'specifications'. Call them functional and safety requirements, tickets, personas, user stories, or any name, but you have to do them to be able to work with the devs, and describe to your customer and users what you have actually developed. the 'lots of things [that] cannot be' scare me as a junior engineer. I feel like they are made by these shady companies that offer 2 interns and a junior, to get you a turnkey solution within 12 hours. It also gives me back bad memories of homework made at the last minute in uni, and I would never do that again. And as far as I saw in both cases, the resulting software is painful to use or to evolve afterwards.
fragmede 4y ago
That's a very windows-centric view of the past. And with good reason too! Windows was utterly dominant back then. Still, Slackware was 7 years old by the year 2000. Running the 2.2 Linux kernel, compiled with open source GCC. Websites were cgi-bin and perl. Yeesh I've been running Linux a long time... On the windows side, NSIS was an open source piece of tooling released that year. And I was writing Windows programs in Visual Studio with MFC.
- PaulDavisThe1st 4y ago
  > That's a very windows-centric view of the past. And with good reason too! Windows was utterly dominant back then. Running servers on Windows? Yeah, a few people who didn't know better did that, but it would be completely inaccurate to describe Windows as "completely dominant". It ruled the desktop (and to a large extent still does), but it barely made it to parity with *nix systems on the server side before Linux (and FreeBSD in some cases) punched down.
  - scarface74 4y ago
    A few people? IIS had 37% market share by 2000. https://www.zdnet.com/article/how-does-iis-keep-its-market-share/ https://www.zdnet.com/article/how-does-iis-keep-its-market-s...
    - PaulDavisThe1st 4y ago
      Yep, that's a few people. That was about it's peak market share, until a brief spike circa 2017 and then it crashed and burned into obscurity.
      - scarface74 4y ago
        A third is a “few”?
        PaulDavisThe1st 4y ago
kasey_junk 4y ago
22 years ago I was programming on an almost entirely open source stack. Linux servers, vim, Perl and we paid for sybase. We used CVS for source control and when I heard about sourcesafes restrictions I was shocked. We had unit tests, though it was your own job to run them before merging. If you broke them you were shamed by the rest of the team. We also had a dedicated lab for automating functional tests and load testing using Mercury interactives tooling (don’t miss that) that we would use to test out before upgrading our servers. We used the techniques outlined in Steve McConnell’s Rapid Development, a sort of proto-agile (and editorializing it got all the good parts right while scrum did the opposite).

DamonHD 4y ago

I agree with a lot of that - I had to 'invent' unit tests for one of my clients for example for their production code. I managed to swerve MS tooling much of the time, one way or another. For example, I worked a lot with Sun workstations SunOS/Solaris.

quickthrower2 4y ago
Thats nice. I think MS programming stacks were most popular in the UK outside of universities (universities would also have Unix, Oracle DB and SunOS). I guess in California it would more likely skew Unix/Sun?
- DamonHD 4y ago
  I (a) ran a very early Internet provider and then worked in (b) oil and (c) finance where good networking, speed and reliability were enough to make *nix a sensible choice. Though (for example) the finance world tried to move to MS to save money, and indeed I got paid a lot to port and maintain and optimise code across platforms including MS, the TCO thing would keep biting them...

Traubenfuchs 4y ago

I had all of this 11 years ago and it was BLISS. Oh MS source safe and it's locked files! No merge conflicts or rebasing clownery, ever! It forced two people working on the same code to sync and this avoided so many conflicts. Customers called with small bug reports, I could fix them in 5 minutes and deploy to production right from eclipse. Modern agile development is hell.

fragmede 4y ago
Nothing's stopping you from implementing file locking on a social level! "Hey I'm gonna be working in the foo/ subdir this week, mind staying out of there till next week?"
robertlagrant 4y ago
Random agile comment at the end of a comment on source control.

NayamAmarshe 4y ago

That makes me wonder, without all the unit tests and all the 'necessary' things we do to our codebase, did any of it really help? Are modern codebases with modern practices less buggy than the ones from 20 years ago?

hinata08 4y ago
In 1988, Airbus delivered the first A320 with electronic flight commands, which was safe. In 1998, the RATP inaugurated line 14 of the metro in Paris, which was fully automated, after formally proving that its software would never ever be able to bug. Gitlab didn't exist back then, and yet these companies made a code that was safe. I guess the main driver of code quality is whether the company cares, and has the proper specifications, engineering before coding, and quality management procedures, before the tech tooling. It certainly is simpler now to make quality code. But don't forget that software used to be safe, and it was a choice of companies like Microsoft, with Windows, or more recently Boeing with the 737 Max, to let the users beta test code and patch it afterwards (Aka early, reckless agile) So yeah, modern codes look less buggy. But it's mainly because companies care IMO.
- PaulDavisThe1st 4y ago
  > I guess the main driver of code quality is ... picking a task for which can be implemented using the sort of processes you describe. Lots of things cannot be.
  - hinata08 4y ago
    Quality assurance and software engineering can be applied everywhere, no matter the processes you use to create and deliver the code. Methods and tools would be different, depending on context, but ANY serious company ought to do quality management At the very least, know your code, think a few moves ahead, make sure you deliver a safe code, and apply some amount of ISO9001 at the company level (and hopefully much more at any other level) Also, a security analysis is mandatory for both industrial code and for IT applications, thanks to standards, laws like the GDPR its principle of privacy by design, and contractual requirements from serious partners. You risk a lot if your code leaks customer data or crashes a plane. it's the same for having 'specifications'. Call them functional and safety requirements, tickets, personas, user stories, or any name, but you have to do them to be able to work with the devs, and describe to your customer and users what you have actually developed. the 'lots of things [that] cannot be' scare me as a junior engineer. I feel like they are made by these shady companies that offer 2 interns and a junior, to get you a turnkey solution within 12 hours. It also gives me back bad memories of homework made at the last minute in uni, and I would never do that again. And as far as I saw in both cases, the resulting software is painful to use or to evolve afterwards.

fragmede 4y ago

That's a very windows-centric view of the past. And with good reason too! Windows was utterly dominant back then. Still, Slackware was 7 years old by the year 2000. Running the 2.2 Linux kernel, compiled with open source GCC. Websites were cgi-bin and perl. Yeesh I've been running Linux a long time... On the windows side, NSIS was an open source piece of tooling released that year. And I was writing Windows programs in Visual Studio with MFC.

PaulDavisThe1st 4y ago
> That's a very windows-centric view of the past. And with good reason too! Windows was utterly dominant back then. Running servers on Windows? Yeah, a few people who didn't know better did that, but it would be completely inaccurate to describe Windows as "completely dominant". It ruled the desktop (and to a large extent still does), but it barely made it to parity with *nix systems on the server side before Linux (and FreeBSD in some cases) punched down.
- scarface74 4y ago
  A few people? IIS had 37% market share by 2000. https://www.zdnet.com/article/how-does-iis-keep-its-market-share/ https://www.zdnet.com/article/how-does-iis-keep-its-market-s...
  - PaulDavisThe1st 4y ago
    Yep, that's a few people. That was about it's peak market share, until a brief spike circa 2017 and then it crashed and burned into obscurity.
    - scarface74 4y ago
      A third is a “few”?
      - PaulDavisThe1st 4y ago

kasey_junk 4y ago

22 years ago I was programming on an almost entirely open source stack. Linux servers, vim, Perl and we paid for sybase. We used CVS for source control and when I heard about sourcesafes restrictions I was shocked. We had unit tests, though it was your own job to run them before merging. If you broke them you were shamed by the rest of the team. We also had a dedicated lab for automating functional tests and load testing using Mercury interactives tooling (don’t miss that) that we would use to test out before upgrading our servers. We used the techniques outlined in Steve McConnell’s Rapid Development, a sort of proto-agile (and editorializing it got all the good parts right while scrum did the opposite).