My straightedge tattoo is on the back of my left hand. Like many, I gave it up later in life. No shame in that, so long as you can avoid assaulting subordinates or killing people with your car.
In all seriousness, there were SO MANY bad decisions in the original story. They just happen to all belong to Joe. I have no doubt he'd have made different choices while sober. But it's not the fault of the "alcohol culture" or "tech", it's Joe's.
I agree. I'm pretty sure the diaspora team wasn't expecting such a huge response and priced their rewards accordingly. "What is someone donates 1/5th of what we need? Let's send em a computer!"
It's an interesting, if severely opinionated, analysis. The author makes a sound argument, but I think he's wrong. The landscape has changed a lot in the two years since Appleseed was abandoned.
Also, it used to be that facebook was only used by the savvy folks. Now my grandmother has a facebook account.
If they made a one-click installer that ran on my iMac and automatically discovered all of my media, then configured it into a personal web server, then allowed me to friend people via email, I'd probably love it. I might even pay for it.
Nice product. Now, stop smoking and go off the Red Bull binge so you can get your thinking cap on for the next step. Good work. I think it'll gain some traction.
Oh, I dunno. I think you can get more done with a small group of super-smart guys the you could with a big group of mediocre ones (isn't that already an axiom?)
I think the client in this story tried to staff up the way a big waterfall or java project typically scales up: hire as many cogs as you can and give them each a little module to work on. In essence, they want a big group of mediocre developers.
A bummer, but perhaps a failing of the consultant. With any adoption of new technology or process, you have to prep the client for uncomfortable changes. Like paying more to fewer developers, or starting work without a 300 line mpp project plan, or whatever.
Sometimes in our roles as consultants, that's the most important job.
Q: "Dr. Anasastio, can you recommend a different editor from emacs? It's so hard to work with. Can we use pico or jot?"
A: "No. Emacs is THE editor. If you plan to work in computer science, you have to know it."
Though I personally use TextMate for most coding these days, I can certainly see his point. 15 years later, emacs is still relevant and powerful (and free).
Find me another editor you can say that about, and I'll pay you $5. (vi doesn't count: it's only relevant because sysadmins could fit it on a floppy, and now it's vim anyway.)
I used to be an Enterprise architect for a Fortune 500 company. We did many of the things you are asking about. Here are my answers:
1. Yes, you can. However, there will be tradeoffs. One important piece of sharing business logic involves sharing instances of running code, not just the logic itself. It's tough to implement a singleton in a set of stored procs. I'd recommend that you leave stored procs for the kinds of logic that you might code into a web service: transactional concerns that have a complicated set of steps.
2. Yes, that's a popular approach, and for good reason: the objects you create against the persistence store are sharable at the instance level.
3. It will scale less-well than an architecture with a solid middle tier, but it's impossible to put a user-count on it without knowing much much more. If you pick a commercial RDBS like Oracle or Sybase (and many people don't like to do that), you will find that there are a lot of expensive but effective scaling mechanisms to handle this. It's usually cheaper to invest in a decent middle tier, a caching server, and scale that way.
4. That's not necessarily true. Portability is nice, but there are many other reasons to pull the business logic out of the database. For example, it's hard (but not impossible) to implement an event-driven system where transactions will fire off other business events downstream when you're using a stored procedure set as your logic layer. You can do it, but you end up with triggers or batch jobs that reduce the real-time processing capabilities of the whole architecture.
5. P/L SQL is pretty powerful, but I still have my logic in objects rather than in Oracle. I can introduce caching and other sscaling strategies easier this way.
Though I use and like Oracle, I'd steer you away from it unless you have a really good reason to buy it. It takes a lot more care-and-feeding than MySQL, the licensing model becomes oppressive when you start to need to cluster the DB, and experts in the area are expensive.
Hibernate is a good framework. Why are you resisting the use of it? If you want to go heavy on the stored procedures, check out the iBatis framework. It's really good at ORM and stored procs.
The slant of this article seems to be mostly steering people away from outsourcing. I understand the motivation, but I disagree in some cases.
Outsourcing is always a touchy topic with hackers and techies like me. Nobody likes to consider sending work offshore that they themselves either used to do, or at least consider critical to their business.
My take on outsourcing is: Don't Outsource Your Brains.
My meaning is: it's useful to outsource pieces of your business that are not core to your strategy. HR, Benefits Management, Software Testing, and Development can all be candidates for outsourcing under some circumstances.
If you're a software or technology company, it may not be a good idea to outsource development. Or, it could be a good idea to outsource implementation of the mundane, easy parts of your application after your Chief Architect has put a solid framework together, so that he or she can move on to solving tougher problems.
If you're a t-shirt printing company, then outsourcing your e-commerce, SEO, and other technical functions could be a great idea, so you can focus on making the business of printing t-shirts better.
Shoot. I am a techie, and I think S3 and EC2 are great ways to get a business started at a low cost. Because managing infrastructure is not my core competence.
In all seriousness, there were SO MANY bad decisions in the original story. They just happen to all belong to Joe. I have no doubt he'd have made different choices while sober. But it's not the fault of the "alcohol culture" or "tech", it's Joe's.