I'll preface my comments by stating that I regularly order through Amazon.com and have never had a customer service-related problem.
This interview, while I'm sure sincere on the part of the CTO, comes across as a recruiting pitch. Obvious fallacies:
"Developers themselves know best which tools make them most productive and which tools are right for the job."
This sort of development mishmash depends on the developers never leaving (which most do after 2-3 years). Maintenance is, at best, nightmarish and leads to a patchy (with apologies to Apache) mess. FWIW, most developers seem to jump into coding right away with no thought for architecture or design.
"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."
Hmm, so the developers manage themselves. What a great job being a manager must be there.:-)
"Developers are like artists; they produce their best work if they have the freedom to do so"
In my experience, most developers are nothing like artists and more closely resemble petulant, undisciplined children. Often they ignore the most basic principles of good software development (like version control, automated build and test suites, documentation, etc.) because "those are boring".
"I think part of the chaotic nature--the emerging nature--of Amazon's platform is that there are many tools available"
Wow, CTO speak at its finest to explain the disorganized nature of the organization.
"As a result of this principle, we have many support tools that are of a self-help nature."
See my point above about documentation being boring.
Comments I've heard from people who work at Amazon:
Low pay - it's a great place for budding "artists" fresh out of school to build "experience" that has to be unlearned at a more organized shop.
Dot-Com mentality - Lots of excuses for your desk being a door on two filing cabinets as well as the lack of organization.
Turnover rate - as soon as people get experience, they leave for better paying jobs; Amazon is *always* hiring.
The Programmer is God syndrome - that's right, they're not just misunderstood artists any more.
Programming for the Java Standard Edition is not the same as programming for the Java Micro Edition. The JME JVM is just about as non-standard across embedded devices as it gets. Best practices in JME are to use as few classes as possible to avoid as much of the overhead inherent in the class loader. Due to these inconsistencies, one has the issue of potentially having to debug everywhere due to a non-standard platform implementation. The wireless carriers are pushing for a "standard" embedded JVM, but are years away from realizing anything from the OEMs. In the meantime, worst practices are still used to create applications (most notably building monolithic applications with no use of MVC).
JME apps are also measurably slower on embedded devices than a natively compiled binary. Not a good thing for the embedded space where the processors are not particulary powerful. The argument that "devices are getting more powerful and have more memory" is at best silly since battery life is not getting any longer (shorter in fact due to the larger screens, more powerful processors, and memory).
Other technologies, like Adobe's FlashLite, are positioned to provide a uniform presentation platform long before the issues with embedded Java will be worked out. That means that business logic layer is next and for the most part I'll take faster with fewer CPU cycles over a non-existent WORA promise. Of course, that makes it harder for developers so perhaps it will ensure that embedded space development doesn't become the same kind of commodity as "mainstream" development.
I hope that Yahoo remembers how Sybase "profited" by their partnership with Microsoft. Microsoft got an enterprise-class RDBMS and Sybase got, well,......
If you don't like the prices, don't go to the concert. It's a variation on the "vote with your feet" theme, but artists and record companies will continue to jack up the prices until people simply say no.
The P2P "pirating" argument has never held water and continues to be an unbelievably leaky sieve used as an excuse for a bad business model. Adapt or perish.
Yes, let's not teach programming concepts
on
Build a Program Now
·
· Score: 1
since real business people don't need "Developer Hacks" to construct applications. After all, they can secure their positions with a "spreadmart" using VBA. Really, it's that simple.
OK, spleen vented.
The real story is that M$ has been trying to lose VB (in any form) for several years. However, it's installed base keeps pushing for them not to drop the product.
IMHO, people should be able to use whatever language they want (and yes Virginia, if you are disciplined you can write good software in *any* language with the converse being true as well). However, a lot of the schlock that's out there comes from people who "don't know how to program". Having had to clean up a ton of this crap over the years, I'd rather people learn how to program , not just build a program thank you!
For those that choose to read the above as VB-bashing, let me make it clear that it has nothing to do with VB but rather the continued attempt to dumb down the profession.
1) The "internet" was built and funded primarily by the US 2) Most members of the UN are in arears on their membership financial responsibilities to offset the cost of operations 3) Get over it
While I applaud the effort to create a dependable operating system , dead-slow dependability is an academic exercise at best. However, we should keep in mind that this is an R&D project and therefore by definition is an academic exercise from which some practical lessons/applications may arise.
I will note that I have never had a client ask me to make an application perform more slowly though....
is that most folks don't understand the point of process and follow the letter of the law (or worse, claim to follow it but really aren't) without understanding the hows/whys associated with using a process. Pragmatism seems to fly out of the window with either draconian enforcement of artifacts or processes that bring little or no value "because they're part of the process" on one extreme to all process being thrown out on the other extreme. The worst cases are where business buy into either create "one process to bind them and in the darkness find them" (ooop, I meant to say one process for all projects) without allowing for the process to be tailored or have individuals who bring no real value other than to create more processes to hide the fact that they really bring no value.
In my nearly 30 years of experience, I've worked across the entire spectra of process levels and what I have learned is that you inevitably have to tailor the process to the project based on things in the process that bring real value. Too often I've seen project teams of 5-10 members saddled with a process designed for a team of 50-100 members because "that's the company process".
RUP is no better or worse than any other process on its own. It can be tailored to scale up and down like any other process. Unfortunately, it has come to be associated with nothing more valuable than overhead thanks to the way it's implemented (thank you major consulting firms whose sole focus is to charge senior consultant salaries for junior consultants and then bilk, er, milk the customer for all they're worth).
I think that people fresh out of school should seek out salaried positions for the first 1-5 years to build experience (learning the real consequences of a missed deadline is the single best lesson during this timeframe). After that, I think they should think seriously about going into the contract market. The "risk" associated with being a contractor (depending on your location) is no more than that of an employee. It's just a matter of different illusions/perceptions. The best job security, in my (not so) humble opinion, is always the ability to secure the next job . Unfortunately, most people tend to be too timid to realize that in most cases a company will take care of the bottom line, not the employees, first.
Given several names in the industry have noted that college degrees are little more than Java certifications these days, I'm pleasantly surprised to see that computer science is still taught instead of being yet another language-specific implementation set of courses. The sad truth is that while there is nothing wrong with Java as a language, per se, most college graduates come out knowing little else than how to program in Java. Many of them that I've spoken to or have worked with didn't get much in the way of data structures, or any other advanced topic because the coursework seems to be focused specifically on programming, not learning the theory behind the programming. Of course, their justification was that they wanted to get a job right out of college. It's sort of sad, because we have a generation of "Java Programmers" who will be lost when the next disruptive language/paradigm occurs because they won't have the background to deal with it.
OK, so how come we think of IBM as being "Big Blue" and not Microsoft if blue is Microsoft's corporate color? Come to think of it, the only blue that I know of that associated with Microsoft occurs when the OS takes a dump..........
High school kids are not great strategic (or tactical) decision makers. I'd hate to bet my company's future enterprise infrastructure on what they think is "c00l".
CIOs have a lifespan of typically 3-5 years and they make all of their plans around that lifecycle. Ergo sum, I'm not confident in their ability to really do "strategic" planning for a company because they're focused on how to get their bonuses and golden parachute.
Generally, innovation comes from below as a grassroots movement. It rarely comes from above because most CIOs are risk averse (See #2).
Sadly, corporations do drive more of the marketplace than people think. However, the marketplace being driven is more often the enterprise marketplace rather than the consumer one.
Software development is an expense and the software resulting from development inherently has no more value than the company selling it can derive. However, a 7-8 digit number times any smaller number is still a big number that more than pays for the expense of development. That's a hard economics lesson for some, but it is the fundamental reason why Microsoft (or any other large software vendor) can charge whatever they want for their products (even giving them away to keep market share).
I agree that the better market for smaller software vendors are small/medium businesses. They're typically more interested in solving a problem cost-effectively than perpetuating some feudal fiefdom built by upper- and middle-level management.
Interesting though I find your comment, I feel compelled to point out that Visual Basic is owned by a single vendor and that vendor has every right to do what it will with its own products, even if that means discontinuing them. Microsoft has tried since the late 90s to kill VB and get VB developers to move over to C#. I guess they've finally decided to bite the bullet on that point. The other languages you mentioned have no single vendor owner and do not suffer from the same sort of arbitrary decisions.
Oddly enough, Java is a vendor owned language. While Sun keeps control, it seems more willing to use a community model to ensure continuing growth.
For what it's worth, this is sort of a weird post for me to respond to since it requires defending Sun and Microsoft.
I thought Sun and its legion of Java developers had already declared all other languages were not viable and think that everything should be written in Java?
Hey, just because someone was wrong ten years ago doesn't mean that we can't keep recirculating bad ideas so a new generation can get screwed up by them.
60% (or better) of the total cost of a software system occurs after the initial deployment (read that as enhancement and maintenance)
Most developers simply reimplement an application because there is nothing that documents how the application is supposed to work
Many programmers are ill-disciplined
Many programmers don't spell well
Many programmers don't write well
Many programmers don't know how to design
Programmers who don't know how to design wind up going down a lot of blind alleys
Many programmers choose cryptic names for variables, functions, modules to demonstrate their "kewlness"
Many programmers think the above practice leads to job security
Many programmers don't understand scalability, reliability, etc.
Corollary to the above: Many programmers have never worked on a system larger than a single desktop
Computer science curricula seems to gloss over requirements, analysis, design, and testing in favor of teaching languages
Many programmers don't get the point that you can't bolt on performance or quality after the fact
Many programmers don't pay attention in microeconomics so they don't understand how businesses work
Slashdot Mirror
This interview, while I'm sure sincere on the part of the CTO, comes across as a recruiting pitch. Obvious fallacies:
"Developers themselves know best which tools make them most productive and which tools are right for the job."
This sort of development mishmash depends on the developers never leaving (which most do after 2-3 years). Maintenance is, at best, nightmarish and leads to a patchy (with apologies to Apache) mess. FWIW, most developers seem to jump into coding right away with no thought for architecture or design.
"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."
Hmm, so the developers manage themselves. What a great job being a manager must be there.
"Developers are like artists; they produce their best work if they have the freedom to do so"
In my experience, most developers are nothing like artists and more closely resemble petulant, undisciplined children. Often they ignore the most basic principles of good software development (like version control, automated build and test suites, documentation, etc.) because "those are boring".
"I think part of the chaotic nature--the emerging nature--of Amazon's platform is that there are many tools available"
Wow, CTO speak at its finest to explain the disorganized nature of the organization.
"As a result of this principle, we have many support tools that are of a self-help nature."
See my point above about documentation being boring.
Comments I've heard from people who work at Amazon:
Your mileage may vary.....
Programming for the Java Standard Edition is not the same as programming for the Java Micro Edition. The JME JVM is just about as non-standard across embedded devices as it gets. Best practices in JME are to use as few classes as possible to avoid as much of the overhead inherent in the class loader. Due to these inconsistencies, one has the issue of potentially having to debug everywhere due to a non-standard platform implementation. The wireless carriers are pushing for a "standard" embedded JVM, but are years away from realizing anything from the OEMs. In the meantime, worst practices are still used to create applications (most notably building monolithic applications with no use of MVC).
JME apps are also measurably slower on embedded devices than a natively compiled binary. Not a good thing for the embedded space where the processors are not particulary powerful. The argument that "devices are getting more powerful and have more memory" is at best silly since battery life is not getting any longer (shorter in fact due to the larger screens, more powerful processors, and memory).
Other technologies, like Adobe's FlashLite, are positioned to provide a uniform presentation platform long before the issues with embedded Java will be worked out. That means that business logic layer is next and for the most part I'll take faster with fewer CPU cycles over a non-existent WORA promise. Of course, that makes it harder for developers so perhaps it will ensure that embedded space development doesn't become the same kind of commodity as "mainstream" development.
But your mileage may vary.....
Hmmm, so exactly how much do we owe Jimmy Hoffa? ;-)
I hope that Yahoo remembers how Sybase "profited" by their partnership with Microsoft. Microsoft got an enterprise-class RDBMS and Sybase got, well, ......
'Nuff said.
Don Henley of the Eagles says ...
since real business people don't need "Developer Hacks" to construct applications. After all, they can secure their positions with a "spreadmart" using VBA. Really, it's that simple.
OK, spleen vented.
The real story is that M$ has been trying to lose VB (in any form) for several years. However, it's installed base keeps pushing for them not to drop the product.
IMHO, people should be able to use whatever language they want (and yes Virginia, if you are disciplined you can write good software in *any* language with the converse being true as well). However, a lot of the schlock that's out there comes from people who "don't know how to program". Having had to clean up a ton of this crap over the years, I'd rather people learn how to program , not just build a program thank you!
For those that choose to read the above as VB-bashing, let me make it clear that it has nothing to do with VB but rather the continued attempt to dumb down the profession.
Moderate away.....
or is there a prevalent willingness on the part of the market to accept bad software and write it off as a "1.0" or other dot-zero hardship?
What happened to concepts like human factors, real testing to ensure that the software really works, and oh, I don't know, pride in workmanship?
They won't be able to dictate that you change your business model to work with their software.........
Facts:
1) The "internet" was built and funded primarily by the US
2) Most members of the UN are in arears on their membership financial responsibilities to offset the cost of operations
3) Get over it
While I applaud the effort to create a dependable operating system , dead-slow dependability is an academic exercise at best. However, we should keep in mind that this is an R&D project and therefore by definition is an academic exercise from which some practical lessons/applications may arise.
I will note that I have never had a client ask me to make an application perform more slowly though....
is that most folks don't understand the point of process and follow the letter of the law (or worse, claim to follow it but really aren't) without understanding the hows/whys associated with using a process. Pragmatism seems to fly out of the window with either draconian enforcement of artifacts or processes that bring little or no value "because they're part of the process" on one extreme to all process being thrown out on the other extreme. The worst cases are where business buy into either create "one process to bind them and in the darkness find them" (ooop, I meant to say one process for all projects) without allowing for the process to be tailored or have individuals who bring no real value other than to create more processes to hide the fact that they really bring no value.
In my nearly 30 years of experience, I've worked across the entire spectra of process levels and what I have learned is that you inevitably have to tailor the process to the project based on things in the process that bring real value. Too often I've seen project teams of 5-10 members saddled with a process designed for a team of 50-100 members because "that's the company process".
RUP is no better or worse than any other process on its own. It can be tailored to scale up and down like any other process. Unfortunately, it has come to be associated with nothing more valuable than overhead thanks to the way it's implemented (thank you major consulting firms whose sole focus is to charge senior consultant salaries for junior consultants and then bilk, er, milk the customer for all they're worth).
But your mileage may vary......
I think that people fresh out of school should seek out salaried positions for the first 1-5 years to build experience (learning the real consequences of a missed deadline is the single best lesson during this timeframe). After that, I think they should think seriously about going into the contract market. The "risk" associated with being a contractor (depending on your location) is no more than that of an employee. It's just a matter of different illusions/perceptions. The best job security, in my (not so) humble opinion, is always the ability to secure the next job . Unfortunately, most people tend to be too timid to realize that in most cases a company will take care of the bottom line, not the employees, first.
But your mileage may vary.....
Given several names in the industry have noted that college degrees are little more than Java certifications these days, I'm pleasantly surprised to see that computer science is still taught instead of being yet another language-specific implementation set of courses. The sad truth is that while there is nothing wrong with Java as a language, per se, most college graduates come out knowing little else than how to program in Java. Many of them that I've spoken to or have worked with didn't get much in the way of data structures, or any other advanced topic because the coursework seems to be focused specifically on programming, not learning the theory behind the programming. Of course, their justification was that they wanted to get a job right out of college. It's sort of sad, because we have a generation of "Java Programmers" who will be lost when the next disruptive language/paradigm occurs because they won't have the background to deal with it.
the BSD Stouts and the Windows Lite beer.....
OK, so how come we think of IBM as being "Big Blue" and not Microsoft if blue is Microsoft's corporate color? Come to think of it, the only blue that I know of that associated with Microsoft occurs when the OS takes a dump..........
I agree that the better market for smaller software vendors are small/medium businesses. They're typically more interested in solving a problem cost-effectively than perpetuating some feudal fiefdom built by upper- and middle-level management.
But your mileage may vary.....
http://www-user.rhrk.uni-kl.de/~renn/
Ah, I see the subtlety of the humor was lost....
:-)
With that in mind (from the front page of Apache.org):
# HTTP Server (C)
# Ant (Java)
# APR (C)
# Cocoon (Java)
# DB
# Torque (Java)
# ObjectrRelationalBridge (Java)
# DB Commons (Nothing published, but has phrase "including but not limited to Java"
# Directory
# Apache Directory Server (Java)
# LDAP (nothing published)
# Naming (Java)
# AuthX (nothing published)
# ASN.1 (Java)
# Kerberos (Java)
# MINA (Multipurpose Infrastructure for Network Applications) (Java)
# Excalibur (Java)
# Forrest (Java)
# Geronimo (Java)
# Gump (Java, supports multiple language builds)
# Jakarta (Java)
# James (Java)
# Lenya (Java)
# Logging (Multiple languages)
# Lucene (Java)
# Maven (Java)
# MyFaces (Java)
# Perl (C)
# Portals (Java)
# SpamAssassin (Perl)
# Struts (Java)
# TCL (C)
# Web Services
# Axis (C++, Java)
# WS-FX (C++, Java)
# JaxMe (Java)
# jUDDI (Java)
# SOAP (Java)
# WSIF (Java)
# WSIL (Java)
# WSRP4J (Java)
# XML-RPC (Java)
# EWS (Java)
# Mirae (Java)
# Muse (Java)
# Scout (Java)
# Addressing (WS-FX subproject) (Java)
# Sandesha (WS-FX subproject) (Java)
# WSS4J (WS-FX subproject) (Java)
# Apollo (WS-FX subproject) (Java)
# Hermes (WS-FX subproject) (Java)
# XML
# Xerces (Java, C++, Perl, COM)
# Xalan (Java, C++)
# AxKit (C)
# Batik (Java)
# FOP (Java)
# Xang (JavaScript)
# SOAP (Java)
# Crimson (Java)
# XML-Security (Java, C++)
# Xindice (Java)
# XML Commons (Java)
# XMLBeans (Java)
Now I may have missed a few, but it looks like the majority of the Apache projects are developed in and for Java.
That doesn't bother me, but I wanted to ensure that the source of *my* amusement was obvious.
changing its name to the Apache Java Foundation and oh yes, we also do a non-Java web server? :-)
Oddly enough, there *are* other people working in other languages.......
Interesting though I find your comment, I feel compelled to point out that Visual Basic is owned by a single vendor and that vendor has every right to do what it will with its own products, even if that means discontinuing them. Microsoft has tried since the late 90s to kill VB and get VB developers to move over to C#. I guess they've finally decided to bite the bullet on that point. The other languages you mentioned have no single vendor owner and do not suffer from the same sort of arbitrary decisions.
Oddly enough, Java is a vendor owned language. While Sun keeps control, it seems more willing to use a community model to ensure continuing growth.
For what it's worth, this is sort of a weird post for me to respond to since it requires defending Sun and Microsoft.
I thought Sun and its legion of Java developers had already declared all other languages were not viable and think that everything should be written in Java?
Wonder how long it would take an SR-71 to circumnavigate the globe? Of course, it can't fly solo (at least as far as I know).
Nuff said.....
In the Zend survey, 93% of respondents listed PHP as a primary language and 69% listed HTML.
only 18% of respondents named Java
OK, is it me not understanding the "new math" or does 93% + 69% + 18% = 170%, i.e., greater than 100%? Must be that electronic voting thing again....
Also, HTML is a markup language not a programming language.
The dot-bomb is dead. Long live the dot-bomb.
Sheesh!