3 ms·
Look at how much small teams accomplished in the 80s and 90s. I don’t mean rockstar teams where you know the names of some of the developers on them, today—norm
by vundercind 2y ago
Look at how much small teams accomplished in the 80s and 90s. I don’t mean rockstar teams where you know the names of some of the developers on them, today—normal-ass boring line of business stuff, applications that you maybe know but with no famous names attached, that kind of thing.
Consider how much more efficient we should be with allegedly-better processes and allegedly much better tools.
Look at some of those and estimate the team size and time to complete it now. Consider whether you could even deliver the same thing (say, native applications on two or three platforms) with double the team size and thrice the time, or whether you’d have to compromise and deliver something worse to make that happen.
There’s your answer.
[edit] though actually I think part of this is also because we’re on-average worse at managing companies overall, too.
- throwAGIway 2y agoI was part of such team. We supported one target only - Windows NT 3.5 and better, full-screen resolution 4:3 between 800x600 and 1280x1024, and database was the client's problem - we told them what version of Oracle they have to buy. Is it slow? Probably because your network or server is slow, have fun troubleshooting. Yeah, we were a very performant team because we constrained the project a lot and pushed quite a big chunk of it to the client. Today I work in a team that supports a wide array of operating systems, device form factors, resolutions and aspect ratios, input methods; we maintain the backend and it's up to us to make it secure, performant and fast for users from anywhere in the world; and of course API access. Customer data doesn't fit on one disk and their processing can't be done with one machine, and they have a globally distributed workforce. We are slower because we do much more.
- vlovich123 2y agoYeah I feel like people just don’t understand that the efficiency gains have not kept up with the scope of problems we’ve been tackling and that’s why it feels people used to be great. Games yesterday: worked on certain HW, sound probably required you to jump through hoops to get working, and networking maybe worked on a LAN. If things crashed it was fine because that’s the only thing you ran anyway. Cutting edge graphics for the time but at that time showing an image or playing a video was also an achievement. Games today: supports HW from at least 2 GPU vendors, an insane amount of resolutions and typically basically the same code for PC, PlayStation, XBOX and maybe even Linux and Mac. Sounds and graphics just works. Networking lets you play with people across the continent over the public internet. Oh and the time and effort invested in graphics quality is insane. Teams yesterday: highly motivated engineers who were extremely talented and new every part of the machine Teams today: a mix of highly motivated engineers who are extremely talented with many more who just want their paycheck and to go home of very varying quality of talent. Same expectations of excellence. Machines have gotten very complex that cutting through abstractions is challenging Infrastructure yesterday: sell a database and the business is responsible for maintaining it and having it run well with onsite domain experts to help Infrastructure today: sell almost anything so that you need almost no understanding and expertise of the software you’re utilizing.
- mcbutterbunz 2y ago> Teams today: a mix of highly motivated engineers who are extremely talented with many more who just want their paycheck and to go home These two are not mutually exclusive.
- vlovich123 2y ago> of very varying quality of talent You missed a key part of that sentence. Also, there’s a huge difference between two engineers when one is super motivated and engaged by the work vs someone phoning it in.
- JohnBooty 2y agoWe are slower because we do much more. Yeah. Ultimately, two or three people could still write a "simple" single threaded single user app with constraints similar to the Windows NT app you describe. But hardly anybody would buy it or want it.
- throwAGIway 2y agoWith today's technology I can do myself in hours what used to take our team weeks or months. But indeed, nobody buys stuff like that anymore.
- ryandrake 2y agoEven things like games! Some great games were developed by single programmers back in the 80s and 90s. And then maybe ported by one or two other programmers to computers like the C64, Amiga, Apple II, Atari 2600, ZX Spectrum, Amstrad, Atari ST, NES, and/or Sega Master System. Today, a team of 40 struggles to release a workable game on one system that has to be patched on day zero because of all the bugs. And porting it to even one other system (with the same CPU architecture)? Forgetaboutit.
- vlovich123 2y agoIs this real? You’re comparing AAA games of the Atari era to AAA games today? You can argue that the game companies are focusing on hyper realism at the cost of fun games, but the games we’re playing today are orders of magnitude more complex than in the Atari days. Those Atari games built on today’s technology would take comparatively little time and could be as easily ported. That likely also explains why the game industry is focused on limit pushing AAA titles. It’s a defensible market position of technical advantage whereas competing on “most fun” puts investment dollars at risk because you can be undercut by an underdog more easily. So the big companies just focus on the places where it’s harder for upstarts to compete and why almost all games look and feel very similar.
- dlivingston 2y agoI don't get why more AAA games aren't available on Mac & Linux. For those that use Unity, Unreal or Godot: you just change the build target! Though for bespoke engines, I can imagine creating a new platform backend would be a lot of work.
- startupsfail 2y agoYes, managing software projects had changed, I think. In particular, I see a lot of companies and software projects got influenced by Google Style of Software engineering. Which is a uniquely good fit inside Google and a bad fit outside. Once they bring Basel, Go, Tensorflow and C++ into projects and start refactoring and perfecting theseNamesThatJustHaveToBeCorrectAtTheLevelOfExcellenceThatCanGetAPlusTwoOfXooglerPrinciple then their complexity and costs get to the level of a software engineering project at Google. Without having the quality of engineering workforce and infrastructure that Googlers enjoy. Not a change to the better in the software sector management, in my opinion.