In a post on their blog, 37signals asked for readers to comment in ten words or less, what the phrase “real world” means. They mention how frequently this phrase is used in IT; in fact overused. The question is, if it’s used that much, does everyone mean the same thing when they use it? Do they even know what they mean by it?
I think that certainly many people who use it have a definition of it deep inside their minds. They may not have vocalized it, and really thought it through, but they are aware of a principle which they refer to when they use the phrase. However, I think there is more than one definition or principle behind it. I think it all comes down to your perspectives and goals.
Some will look at the development principles of Ruby on Rails and think that in “the real world”, Rails can’t cut it. Others believe that Rails is a real world solution, whereas Java is a solution for bloated IT departments. Is either belief correct?
Once again, it depends on the goal. I have been focusing on learning Internet Marketing for the past three years. It’s been great to learn some skills that relate to the Internet world, but from a different perspective than web development. Once you get into the Internet Marketing mindset, much of your thinking begins to change. For one, every minute spent designing, developing, testing, and all the project management, team meetings and team management that goes into a typical IT department, is now seen as costly. When an Internet Marketing entrepreneur sees an opportunity in a target niche, they want their online product delivered immediately, because every day not online is lost money and possibly a lost opportunity. These entrepreneurs talk in terms of days to get some software written and online, as opposed to the months that larger enterprises consider for their project timelines.
It would be amusing to them, not to mention completely unacceptable, to be told that something was going to go through a kickoff meeting, team assignments, UML design documents, development, unit testing, weeks of QA and integration testing before going live. Ten developers, a project manager, three QA testers, a DBA, a system administrator, department managers, tech writers, graphic designers, etc. To these entrepreneurs, this much bloat is not “real world”. It may be considered necessary for a large corporation to be as “safe” as possible, but it’s not agile enough to respond to online opportunities. I’ve seen opportunities to make $250,000 that literally lasted only a month.
On the other hand, if you went to the Java enterprise development team and said, we need to have a web site that manages the following eight sets of data, with user registration (including email verification, lost passwords, etc), functionality for regular email notifications to subscribers, and a nicely designed front end, and we need it in five days, they would respond, “that isn’t the real world!” They probably couldn’t even find time to schedule the kick off meeting that quickly.
In my 12 years of web development experience, I have heard more times than I can count, the marketing department give a timeline from their expectations which the IT department countered was unrealistic and impossible. The marketing department is frustrated with the time it takes to get to market, and the IT department is frustrated with the tight deadlines and long hours it takes to meet expectations. This is the real world. A constant battle between business leaders and developers to get to market fast.
Only you can decide for yourself which real world you want to belong to. Myself, I used to belong to the IT department real world of all the steps needed to get to market, but as I studied Internet Marketing I began to see every minute of my time as cost and delay toward making money. Now I look for short cuts, not in quality, but in process and development time. Streamlining; cutting the bloat that has crept in over the years, particularly, from my point of view, in the Java Enterprise. I prefer a short development life-cycle, keeping the requirements for each cycle short and to the point. The smaller the feature set, the shorter every sub-cycle is (design, testing, etc). I prefer online task management eliminating the project status meeting, where 15 people take turns telling the PM the same information they could have entered into some software in five minutes. I prefer streamlined communications and small teams. Get the product out there, and immediately start working on an update. This provides for more flexibility within the market, and allows businesses to respond to perceived online opportunities quickly. It will also reduce developer stress and burnout. But, it also requires less development technology bloat, that I believe is now a large part of Java web development. Java doesn’t have to be bloated, and neither does the development life-cycle. But it has become that way, and it will take some outside the box thinking, and a different perspective to make the process more efficient, less stressful, more financially lucrative, and ultimately, a whole lot more fun.
, IT Management