That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.
Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.
As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.
This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.
In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.
...that we shouldn't want things like identities, families, and lives. It is a joy for us to be interchangeable work-bots. Dissention must be expunged so that we can be assimilated. Obedience is happiness!
Ninja Gaiden 1 or 2 would have been a very different conversation. The way I see it, the Aussies found a way to rack up a symbolic victory to look good to hyper-sensitive parents without actually hamstringing a blockbuster game.
Focus, focus, focus on getting that product out the door; that alone will take everything you've got. Open-sourcing involves managing a team of people who are distributed in geography and in time zones, and may not care about the mission of your business. It's way more headache than you need right now; I'd definitely not try to add that to your already-full plate.
Open-sourcing isn't really a marketing tool. Once you have a harem of happy customers, they will provide all the buzz you need, and then if you're profitable, you might have some breathing room to think about helping society.
The single biggest line item on my (and probably many people's) productivity costs is interruptions of the form, "hey, I need to answer a question that takes more than a goldfish brain's worth of thought. I'd like you to do that thinking for me."
The second would be, "As my work product, I took a big dump into our codebase. Given that I don't care about anything but going home at 5, and none of our leadership understands what I did anyway, especially since I have two monitors and therefore look smart, why don't you clean it up for me if you are interested in finishing your own work?"
I'd settle for just dumping some dead weight instead of any new technology. Really.
This is one of those problems, such as "the O/R problem," that cannot be solved because it asks an invalid question. I might suggest using it as a koan for Zen meditation.
The actual length of time a project will take arises from the complexities of the existing codebase as well as the rabbit hole of requirements. We can talk about the idea of a "spec" all day, but I've never seen requirements really, truly, set-in-stone finalized before release. Too many decision points always come up that were impossible to foresee without looking at a partially-complete version of the product. Requirements, like code constructs, are an adaptive process that continues all the way through the lifecycle, which is why the industry is flailing around for alternatives to the unrealistic waterfall model.
Thus, the set of actions that lead a team from beginning to end of a project are always, at least partially (and usually mostly) defined only as a function of the current state, and thus can't be fully predicted without actually playing out those actions. They can theoretically be partially predicted, but it's impossible to determine how large a fraction of the whole the resulting prediction is. It's almost never large enough to be considered remotely reliable.
Engineers themselves usually have a gut feeling that time estimates are a waste of time because of the need for this adaptive process. When was the last time you attempted a true end-to-end time estimate on a project where none was asked for by management? More than likely, you instead made a judgment about which path was probably the more efficient use of time, and started down that path with only a rough, order-of-magnitude guess at its length. At each step, your decision to continue was based on (1) how long it had taken so far, and (2) whether you continued to see a fruitful-looking path ahead.
I would argue that the common notion of time estimation in the industry arises mostly from the desire of outside parties (management) to create the illusion that the leaders are in control. I say "illusion" because ultimately, the main power here lies in the structure of the problem, not in any one person's hands. But the reality of being at the total mercy of a complex logic puzzle that can't be reasoned with would make most people very uncomfortable, especially those who are not in engineering. But the illusion of a "classic" hierarchical department with management and labor calms everyone's nerves and allows the workday to roll on, so we engage in activities that support it, including this charade of guessing the future.
Thus, searching for a good method of time estimation in mathematical models may help a bit, but ultimately won't get us there because it is fundamentally an emotional process. Look to the "soft" elements of team dynamics and department culture to do the rest: do people need to feel involved? Use a method where everyone contributes a number. Is the manager very controlling? Let him/her make up a number. Either way, there will then need to be a process of reconciliation between the illusion and reality, which again, is a process that depends on the emotions of the business. Perhaps a leader apologizes. Perhaps a "tiger team" is formed to improve estimation, or there is a department offsite to talk about it. It may feel unsatisfying that none of these actually brings the estimate and reality together, but like I said at first, trying to do that is asking the wrong question.
That's really the crux of all of this. The fact that the founders of both went to Stanford is hard proof of what I've always said: they are all part of a secret railroad monopoly plan hatched by Leland Stanford in the 1800s.
That's why he orchestrated the Hoover presidency and built the linear accelerator facility, which looks like the all-seeing eye when seen from the air. Google is really just a corporate front for the Stanford band, whose shadowy aim is to take over the world from their trailer, where Leland Stanford is kept cryogenically frozen!
You're right that many people will probably regard this as splitting hairs, and this in itself is a pretty big issue. Names (from "top-level" names like application titles down to the names of lowly index variables) are critically important in usability, as is documentation.
Yet try as I might, with the notable exception of Python, I've never been able to pick up an open-source product of any complexity that I'm not familiar with, without buying an O'Reilly book or something of the like. Flame me if you will for "not trying hard enough," but it seems to me like having to try hard goes against the definition of usability in some ways. This makes for a pretty big hidden cost.
Open-source projects are the products of engineers working on something they feel is personally important, and it's perhaps unsurprising that communication with the end user (at least on the level of completeness and polish that larger companies need to demonstrate) is not given much priority. But the end users are what will drive the victory or loss of Linux on the desktop, and I think they are already voting with their mice.
And say what you want about Microsoft - but the level of effort they put into this front (from the easy-to-understand language in setup to the MSDN) is way ahead of what I've seen from the Linux world. I think they are the ones to be applauded in this case.
Let's take a step back here before we all start grabbing our pitchforks and torches, folks! I feel like I'm stating the excruciatingly obvious here, but don't we sound a wee bit Luddite? Somehow I expected the Slashdotters to be a bit more aware that change is a part of business, and it's our own responsibility to stay ahead of the curve. Not only that, but the socialist bitching about "profit is evil blah blah fight the Man" is really something we as reasonable geeks should be a few levels above. Hopefully this crap is just emotional venting and not anyone's real mindset.
The fans of a given game can't reasonably be called hardcore until some of them die playing it (as with Diablo 2 a couple years ago). I see the Starcraft guys still lack commitment.
Using the legal defense of claiming a malicious hacker broke into your system (or, not even that, a virus) has already been successfully used to defend against child pornography charges. By this precedent, if any of these cases ever went to court, they might stand a good chance of demonstrating at least a shadow of a doubt. Sadly, paying the 3 grand in bribe money does still seem like the least risky proposition. Kudos for our legal system!
My Satan-spawn manager at one startup job was funneling large sums of money to his friend, who ran an offshoring outfit in China, for writing horribly obfuscated code (intentionally, of course, for job security). Naturally, after I pointed out our awful code to the Prince of Darkness (aka our CEO), I was hated by said manager. The CEO said "no excuses; make it work, or else."
After tearing my hair out for months about this, I refused to work on a weekend and was immediately fired. In the two days after that, my blood pressure went down by 25 points (not an exaggeration!).
I hear they're being sued now for industrial espionage. The embezzling thing has yet to hit the fan.
Actually, "Ketsu" also roughly translates to "ass," in the sexual sense (as in, "I'm gonna get me a piece of ass tonight"). No, really, it actually does; look it up. I took the name to be an irreverant pun on "Tetsujin," which would be Stalin's name ("steel") translated From Russian into Japanese. A stretch of linguistics? Or a corporate Easter Egg? The world may never know.
Though the parallel between Chernobyl and Silent Hill needed to be made, it should not reflect any real humor from my end. This sort of page is what the internet is for, and as geeks, we owe it a solemn hats-off.
Here's a mirror with relative-ized links, corrected page 16 reference, and minus the crappy Angelfire adware.
http://www.davidweaver.com/chernobyl/page2.html
Slashdot Mirror
That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.
Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.
As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.
This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.
In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.
This one is safely ignored.
...that we shouldn't want things like identities, families, and lives. It is a joy for us to be interchangeable work-bots. Dissention must be expunged so that we can be assimilated. Obedience is happiness!
Ninja Gaiden 1 or 2 would have been a very different conversation. The way I see it, the Aussies found a way to rack up a symbolic victory to look good to hyper-sensitive parents without actually hamstringing a blockbuster game.
I haven't seen one in a long time. My boss tells me that 7000 man-years isn't anything he shouldn't expect in a good, hard 3-day push.
Focus, focus, focus on getting that product out the door; that alone will take everything you've got. Open-sourcing involves managing a team of people who are distributed in geography and in time zones, and may not care about the mission of your business. It's way more headache than you need right now; I'd definitely not try to add that to your already-full plate.
Open-sourcing isn't really a marketing tool. Once you have a harem of happy customers, they will provide all the buzz you need, and then if you're profitable, you might have some breathing room to think about helping society.
The single biggest line item on my (and probably many people's) productivity costs is interruptions of the form, "hey, I need to answer a question that takes more than a goldfish brain's worth of thought. I'd like you to do that thinking for me."
The second would be, "As my work product, I took a big dump into our codebase. Given that I don't care about anything but going home at 5, and none of our leadership understands what I did anyway, especially since I have two monitors and therefore look smart, why don't you clean it up for me if you are interested in finishing your own work?"
I'd settle for just dumping some dead weight instead of any new technology. Really.
This is one of those problems, such as "the O/R problem," that cannot be solved because it asks an invalid question. I might suggest using it as a koan for Zen meditation.
The actual length of time a project will take arises from the complexities of the existing codebase as well as the rabbit hole of requirements. We can talk about the idea of a "spec" all day, but I've never seen requirements really, truly, set-in-stone finalized before release. Too many decision points always come up that were impossible to foresee without looking at a partially-complete version of the product. Requirements, like code constructs, are an adaptive process that continues all the way through the lifecycle, which is why the industry is flailing around for alternatives to the unrealistic waterfall model.
Thus, the set of actions that lead a team from beginning to end of a project are always, at least partially (and usually mostly) defined only as a function of the current state, and thus can't be fully predicted without actually playing out those actions. They can theoretically be partially predicted, but it's impossible to determine how large a fraction of the whole the resulting prediction is. It's almost never large enough to be considered remotely reliable.
Engineers themselves usually have a gut feeling that time estimates are a waste of time because of the need for this adaptive process. When was the last time you attempted a true end-to-end time estimate on a project where none was asked for by management? More than likely, you instead made a judgment about which path was probably the more efficient use of time, and started down that path with only a rough, order-of-magnitude guess at its length. At each step, your decision to continue was based on (1) how long it had taken so far, and (2) whether you continued to see a fruitful-looking path ahead.
I would argue that the common notion of time estimation in the industry arises mostly from the desire of outside parties (management) to create the illusion that the leaders are in control. I say "illusion" because ultimately, the main power here lies in the structure of the problem, not in any one person's hands. But the reality of being at the total mercy of a complex logic puzzle that can't be reasoned with would make most people very uncomfortable, especially those who are not in engineering. But the illusion of a "classic" hierarchical department with management and labor calms everyone's nerves and allows the workday to roll on, so we engage in activities that support it, including this charade of guessing the future.
Thus, searching for a good method of time estimation in mathematical models may help a bit, but ultimately won't get us there because it is fundamentally an emotional process. Look to the "soft" elements of team dynamics and department culture to do the rest: do people need to feel involved? Use a method where everyone contributes a number. Is the manager very controlling? Let him/her make up a number. Either way, there will then need to be a process of reconciliation between the illusion and reality, which again, is a process that depends on the emotions of the business. Perhaps a leader apologizes. Perhaps a "tiger team" is formed to improve estimation, or there is a department offsite to talk about it. It may feel unsatisfying that none of these actually brings the estimate and reality together, but like I said at first, trying to do that is asking the wrong question.
That's really the crux of all of this. The fact that the founders of both went to Stanford is hard proof of what I've always said: they are all part of a secret railroad monopoly plan hatched by Leland Stanford in the 1800s.
That's why he orchestrated the Hoover presidency and built the linear accelerator facility, which looks like the all-seeing eye when seen from the air. Google is really just a corporate front for the Stanford band, whose shadowy aim is to take over the world from their trailer, where Leland Stanford is kept cryogenically frozen!
The world, I say!
Wow, this just gives me flashbacks of a certain...incident...after I played Katamari Damacy, involving a medicine ball and a cat...
You're right that many people will probably regard this as splitting hairs, and this in itself is a pretty big issue. Names (from "top-level" names like application titles down to the names of lowly index variables) are critically important in usability, as is documentation.
Yet try as I might, with the notable exception of Python, I've never been able to pick up an open-source product of any complexity that I'm not familiar with, without buying an O'Reilly book or something of the like. Flame me if you will for "not trying hard enough," but it seems to me like having to try hard goes against the definition of usability in some ways. This makes for a pretty big hidden cost.
Open-source projects are the products of engineers working on something they feel is personally important, and it's perhaps unsurprising that communication with the end user (at least on the level of completeness and polish that larger companies need to demonstrate) is not given much priority. But the end users are what will drive the victory or loss of Linux on the desktop, and I think they are already voting with their mice.
And say what you want about Microsoft - but the level of effort they put into this front (from the easy-to-understand language in setup to the MSDN) is way ahead of what I've seen from the Linux world. I think they are the ones to be applauded in this case.
Let's take a step back here before we all start grabbing our pitchforks and torches, folks! I feel like I'm stating the excruciatingly obvious here, but don't we sound a wee bit Luddite? Somehow I expected the Slashdotters to be a bit more aware that change is a part of business, and it's our own responsibility to stay ahead of the curve. Not only that, but the socialist bitching about "profit is evil blah blah fight the Man" is really something we as reasonable geeks should be a few levels above. Hopefully this crap is just emotional venting and not anyone's real mindset.
The fans of a given game can't reasonably be called hardcore until some of them die playing it (as with Diablo 2 a couple years ago). I see the Starcraft guys still lack commitment.
I long for combat!
Using the legal defense of claiming a malicious hacker broke into your system (or, not even that, a virus) has already been successfully used to defend against child pornography charges. By this precedent, if any of these cases ever went to court, they might stand a good chance of demonstrating at least a shadow of a doubt. Sadly, paying the 3 grand in bribe money does still seem like the least risky proposition. Kudos for our legal system!
They'll pry my porn from my cold, dead, sticky hands!
My Satan-spawn manager at one startup job was funneling large sums of money to his friend, who ran an offshoring outfit in China, for writing horribly obfuscated code (intentionally, of course, for job security). Naturally, after I pointed out our awful code to the Prince of Darkness (aka our CEO), I was hated by said manager. The CEO said "no excuses; make it work, or else."
After tearing my hair out for months about this, I refused to work on a weekend and was immediately fired. In the two days after that, my blood pressure went down by 25 points (not an exaggeration!).
I hear they're being sued now for industrial espionage. The embezzling thing has yet to hit the fan.
Actually, "Ketsu" also roughly translates to "ass," in the sexual sense (as in, "I'm gonna get me a piece of ass tonight"). No, really, it actually does; look it up. I took the name to be an irreverant pun on "Tetsujin," which would be Stalin's name ("steel") translated From Russian into Japanese. A stretch of linguistics? Or a corporate Easter Egg? The world may never know.
Dave
Though the parallel between Chernobyl and Silent Hill needed to be made, it should not reflect any real humor from my end. This sort of page is what the internet is for, and as geeks, we owe it a solemn hats-off. Here's a mirror with relative-ized links, corrected page 16 reference, and minus the crappy Angelfire adware. http://www.davidweaver.com/chernobyl/page2.html