So some interesting flames from my old buds at JBoss over at Dzone. Was it something I said like, Java EE lost and Spring Won?
I'll be DZoneing regularly. Please give me a hand with ideas for articles for my Infoworld and DZone columns.
Also check out Shawn Deena's mobile post on DZone as well.
Some vendors complained that we left them out. One vendor complained (before the article) that we included them. Other vendors took action and deployed Granny to their own cloud.
Most of the buzz around the cloud has centered on infrastructure as a service (IaaS). However, IaaS is no longer good enough. Sure, you can forgo buying servers and run everything virtually on Amazon's EC2 server farm. So what? You still have to manage it, and to do that you'll have a growing IT bureaucracy. Companies that want to focus on writing their code and not have to think about application servers at all are now looking to platform as a service (PaaS).
NoSQL databases like MongoDB are great for some tasks but not for others. Is it MongoDB's fault if misguided developers use it to solve the wrong problem?
With any new technology comes a wave of marketing happy talk, which in turn leads to inexperienced developers "jumping on the train" of a new fad. Inevitably, these newbies find themselves disappointed that the technology doesn't deliver on their inflated expectations.
Self-taught technologists are almost always better hires than those with a BSCS and a huge student loan
A reporter recently asked me what advice I had for kids coming out of high school. I said, "Go into computer science and you'll probably always have a job." I wonder if I should have said: "Skip college and spend all your time teaching yourself computers."
Especially in America, where an education incurs tremendous debt and most educational institutions teach you so little of what really matters, you have to ask: "Can't I just do this myself?"
You want the best and the brightest money can buy. Or do you? In fact, you're better served by a group of developers with mixed skill levels who focus on getting the job done
A big, important project has launched -- and abruptly crashed to the ground. The horrible spaghetti code is beyond debugging. There are no unit tests, and every change requires a meeting with, like, 40 people.
On the other hand, maybe not. A team of senior developers will often produce a complex design and no code, thanks to the reasons listed below.
I've been credited with coining the term "do-ocracy." When I've had the opportunity to lead an open source project, I've preferred to "run" it as a do-ocracy, which in essence means I might give my opinion, but you're free to ignore it. In other words, actual developers should be empowered to make all the low-level decisions themselves.
When you think about it, the hacker group Anonymous is probably one of the world's most do-ocratic organizations. Regardless of where you stand on Anonymous' tactics, politics, or whatever, I think the group has something to teach developers and development organizations.
Anyone who watches even a small amount of software development is familiar with the scene: The agent, be she new hire or consultant, comes in assuming that success of the project at hand is the goal and that everyone is familiar with its pre-requisites. “Show me to your revision control system” she says.
Some are bad habits to overcome; some are poor decisions forced by managers who don't know what they're doing. Read 'em ... and weep
Writing great software is not that hard. But software developers can be their own worst enemy in trying to code the good stuff because they lapse into sloppy or wrongheaded practices.
Actually, scratch that: The developer's worst enemy is really the eager technical manager who tries to deliver a project faster than possible and pushes developers to engage into ill-advised practices. In high-end enterprise and Web-scale projects in particular, that can result in wholesale disaster.