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.
136 karma · joined June 3, 2008
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.
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.
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.)
No mention of source control, either. Yikes.
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.
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.
It was a great read, thanks.
I'm not sure how Ycombinator views it, but I think you should get some skin in the game. I know it can be tough to jump ship and work on your startup full or even half time, but you can't give yourself any excuses. (Like working IT consulting full time).
That said, outsourcing your development is a fairly common practice.
There are a number of boilerplate "work for hire" and "intellectual property agreement" forms available, but if you're serious about this idea, you could not spend your first $500-$1000 any better than getting a competant attorney to write you one.
You might be able to rely on oDesk or E-lance to provide you with protection. The people who outsource through those platforms are required to agree to the standard "work for hire" terms and conditions.
I'd go the lawyer route, though. If your idea gets traction, you'll eventually need one anyway.
If you have to say you're cool....you're probably not.
Awhile back, YC listed some ideas they wanted to fund. Simplified browsing was one of them. Seems like your technology could be applicable to simplifying the online experience for people who want that.
It doesn't look tuned for that now, but it's an idea.
I'll sign up. Thanks.
I allow outside help (google, etc) because in their work environment, they are permitted to use any reference materials they want.
I also let them ask me questions.
Exact syntax, without the benefit of the compiler or IDE, is unimportant to me. And, candidates that are on the spot to write code on a whiteboard are usually more nervous when working in an unusual medium (who codes on a whiteboard?)
So yes: in my opinion, they should write code in some fashion, and if that medium doesn't include a syntax checker, the simple errors are OK.
These are excellent.
Most are worth debating, some aren't: depending on your audience. I think most people think these are things you "can't ask" because many folks lack an intelligent, informed opinion on the topic, and therefore resort to emotional closed-minded positions that result in little exchange of ideas.
So, intelligent people think: "Maybe I can't ask that question."
And I agree: stop talking in public about it right away.
http://chneukirchen.org/blog/archive/2005/05/lazy-streams-fo...
I am productive late at night, when I can go into the coding zone with little interruption. But that late night time is generally not creative for me.
I've had my Scrum masters come to me twice in the past two years and ask to have a team member removed. One needed to get fired, one needed to be reassigned to a position that better suited his talents.
In both cases, the team experienced an immediate productivity boost and jelled better.
The key for the manager is letting the team know that you trust them enough to bring those issues to you.
I calculated the savings for my company: moving out of a hosted datacenter solution with leased equipment and into a cloud provider's environment will be roughly 50% cheaper. Half price, and scalable on demand.
Sounds like an economizing measure to me.
It's certainly sobering, but it's sloppily done. There are some facts in there, but the synthesis and analysis aren't intelligent. It seems more like wishful thinking.
When I'm shaving yaks, I have one editor tab and 10 browser tabs.
IMO, the best place to find an intern like you're describing is the Computer Science department at your local University. I cold called a well-respected CS professor and ended up with the best programmer I had ever hired. She started full-time three months later.
If it helps them distribute their application more in a more scalable way, or in a more stable way, I'd love to understand how.
My "guess", knowing little about Erlang, is that the server code is simpler....
ScrumWorks (there is a free and pro version) VersionOne (paid only) Jira (paid only, needs plugins)
Banana Scrum is free and looks good. It was talked about on HackerNews awhile back.
After experimenting with lots of this software, my team has reverted to the whiteboard for Iteration Goals, and sticky notes for the iteration's tasks. We've found that you can't beat the tactile qualities of post-it notes.
Items in a software package can be easy to ignore if you don't manage it closely. But if you look at the whiteboard and see more sticky notes in the "pending" column than there should be, you instantly know something is wrong and can dive in.