@xevo @vatoloco2 @modemlooper @mikepratt @qrahaman
2) There seems to be some disappointment regarding the amount of time we’ve spent coding BP-Media versus what the plugin does when you run it on your server. That’s okay. It was planned for, and expected.
So let’s talk about deliverables, dependencies, parametric design, management overhead, and project scope …which are the engineering terms for what many of you are complaining about.
Say you want to fry an egg for your mom. Everybody knows how to fry an egg. You just put a frying pan on the stove, throw in an egg, cook it till its done, and serve it to your mom.
The “deliverable” is the fried egg. The “dependencies” are the frying pan, which is needed to cook the egg, and the stove, which is needed to heat the frying pan.
People frying eggs today have access to the vast amount of experience gained from frying millions of eggs in the past, and can use that experience to estimate how changing parameters will affect the deliverables. How long to cook two eggs instead of one? About the same amount of time. How long to cook an egg really hard? About 50% longer than usual. Frying an egg is a “parametric” problem.
Furthermore, if any dependency in the chain is missing “I don’t have a frying pan to cook the egg”, it can easily be solved by driving to the nearest store and buying a frying pan.
So even starting with no stove, no frying pan, and maybe even no kitchen, I can give you a reasonably accurate time and cost estimate for practically any combination of egg-frying you could possibly think of.
When people talk about “how easy it is to write software” and “huge websites being built in a weekend”, this is the type of design they’re talking about (often without realizing it).
And then there’s the Apple iPod.
All things considered, using an iPod is about as complicated as frying an egg. It also has a dramatically smaller range of inputs (about 20 file types) and only two outputs (audio and video).
There are two main reasons why the iPod took millions of dollars and years of effort to create, despite having the overall UI complexity of a kitchen stove:
a) It has an enormous dependency chain. There are probably 300 different things …from the USB connection to the host computer, to the lithium-polymer battery, to the headphone wires… that *all* have to work before audio files put into the iPod come out as audio in the headphones.
b) It was effectively the first of its kind. While there were a few other primitive MP3 players on the market at the time, Apple had to invent the “essence” of what makes an iPod an iPod, and they had to build huge parts of the dependency chain from scratch.
Its hard to believe the iPod’s been around for over ten years now. Concepts pioneered in the iPod are now taken for granted and used everywhere.
Building BP-Media is a lot more like designing an iPod than frying an egg.
Although there’s tons of open-source software out there that we’ve been able to use to avoid having to write a lot of code, we’ve still had to write huge dependency trees from scratch (like our database class) and design completely new paradigms (like our Page, Album, Media, and Network modules). This work is ongoing and makes it very difficult to give accurate timeline estimates.
In a “typical” software development operation, a significant portion of the development team’s time would be spent building “mock-ups” that would make the plugin appear to work in the user’s browser but wouldn’t actually do anything on the server. These “mock-ups” would be used to demo the plugin to the marketing team and executives, and would then be discarded. This is called “management overhead”.
We’ve chosen to focus our development resources on building-out the dependency chain instead of producing “mock-ups” because we think its a better use of our time. We do realize this has created the appearance of little progress being made despite enormous amounts of code being written.
^F^
