Even as an early software developer I used to look at massive companies and think what a waste, you could do this with so much less!
Today I realize that was partially a failure to recognize the complexity of what was in front of me.
Today I’m thinking about a timeline tool for a game development environment. In isolation it’s not too hard to implement and it’s certainly a solved problem. Flash had it 20 years ago! We should be able to do this in a few sprints, right?
However, it needs to understand the way the game engine works, and it needs to integrate with the engine in a way that’ll let engine development carry on fluidly. This would be possible with loose abstractions most likely, but it becomes very difficult to make these abstractions finely tuned for a simple and well integrated user experience. We don’t want users to need to know anything about the engine. The deeper we go there, the more likely we are to tie ourselves to specific implementation details. Hmmm… So we need this timeline to fit loosely but to also be maximally useful where it counts. There are definitely opportunities to make mistakes here and get bound by tight coupling which we really can’t afford.
There’s also the question of if the engine or any tooling around it needs to know about the timeline. Should we black box it? Our engine team is small, so any major changes there will be very resource intensive… In fact, that decision is crucial because while it could make timeline development easier, it could prevent us from shipping key engine features! Shit, now it’s a very important decision on how we use the team’s time; it’s kind of mission critical.
And that doesn’t begin to touch on how the timeline will fit into the UI, how it’ll integrate with the existing API, and if/what’s missing from the API to make this thing work.
Suddenly this thing I could mock up over a weekend is a massive endeavour that’ll consume a significant portion of the company’s resources. If only we had another dozen people to help us make it happen
Oh, and we’ve got 4 or 5 other super important features to add and they all kind of overlap and interfere with each other.
But we should be able to do this with a couple hackers and a weekend or two, it’ll be easy. Move fast and break it or something.
I’m not saying no company is too large! Some are insanely oversized. Even so, sometimes tech is hard. You don’t want to try having 9 people give birth to a baby in a month or anything silly, but it’s easy to become constrained in this field. Ideas get bigger than your feasible outputs very quickly. Unfortunately, a lot of the ideas are good! You need more people to make it real!
Then of course you’ve got the weird political side of it. But many companies aren’t necessarily up to that game. Sometimes the product you see is only a piece of what’s in the works. Entire teams could be working on stuff that hasn’t materialized yet.
Today I realize that was partially a failure to recognize the complexity of what was in front of me.
Today I’m thinking about a timeline tool for a game development environment. In isolation it’s not too hard to implement and it’s certainly a solved problem. Flash had it 20 years ago! We should be able to do this in a few sprints, right?
However, it needs to understand the way the game engine works, and it needs to integrate with the engine in a way that’ll let engine development carry on fluidly. This would be possible with loose abstractions most likely, but it becomes very difficult to make these abstractions finely tuned for a simple and well integrated user experience. We don’t want users to need to know anything about the engine. The deeper we go there, the more likely we are to tie ourselves to specific implementation details. Hmmm… So we need this timeline to fit loosely but to also be maximally useful where it counts. There are definitely opportunities to make mistakes here and get bound by tight coupling which we really can’t afford.
There’s also the question of if the engine or any tooling around it needs to know about the timeline. Should we black box it? Our engine team is small, so any major changes there will be very resource intensive… In fact, that decision is crucial because while it could make timeline development easier, it could prevent us from shipping key engine features! Shit, now it’s a very important decision on how we use the team’s time; it’s kind of mission critical.
And that doesn’t begin to touch on how the timeline will fit into the UI, how it’ll integrate with the existing API, and if/what’s missing from the API to make this thing work.
Suddenly this thing I could mock up over a weekend is a massive endeavour that’ll consume a significant portion of the company’s resources. If only we had another dozen people to help us make it happen
Oh, and we’ve got 4 or 5 other super important features to add and they all kind of overlap and interfere with each other.
But we should be able to do this with a couple hackers and a weekend or two, it’ll be easy. Move fast and break it or something.
I’m not saying no company is too large! Some are insanely oversized. Even so, sometimes tech is hard. You don’t want to try having 9 people give birth to a baby in a month or anything silly, but it’s easy to become constrained in this field. Ideas get bigger than your feasible outputs very quickly. Unfortunately, a lot of the ideas are good! You need more people to make it real!
Then of course you’ve got the weird political side of it. But many companies aren’t necessarily up to that game. Sometimes the product you see is only a piece of what’s in the works. Entire teams could be working on stuff that hasn’t materialized yet.