On missing the point
Note: the title is way too aggressive for the point I’m making
Having recently moved from all exclusive open source based web development to the more corporate JAVA/.NET conundrum I’m in for a serious cultural shock.
I’ve dabbled with .NET before, especially with desktop applications. When .NET 3.5 beta came out last year I grabbed it and immediately started to learn the ins and outs of WPF and the likes. It was fun, and it wasn’t all that hard at all, especially having a fairly good book to guide me, Pro WPF - Windows Presentation Foundation in .NET 3.0 by Matthew MacDonald.
I used to program in Java, but Swing or J2ME only (wooohoo RTFEditor & MobileVNC). Now I’ve taken up Java EE and all the technologies that come with the bandwagon: Hibernate, Struts, JBoss, Ant, etc. There is plenty of documentation out there, but at times I feel there just isn’t a definitive source for answers (except the class API, which is usually the place where I find answers after scouring through it for 20 minutes).
So, what ’s up with missing the point? Coming from a long time (dynamically typed scripting language) background I used to be accustomed to getting the things done by applying a well defined algorithm:
- imagine it
- get idea on how to build it
- build it. if this fails, go back to step 2.
While this may seem funny to the more mature of the audience, it got me through the years to the point where I could build prototypes in no time and easily discard bad ideas to the point where creatively solving a problem was mostly a process of building up a solution to the problem guided solely by past experiences. I would recognize patterns in problems others would encounter in Java/ASP.NET web development and regard their solutions as obvious.
And that got me to ask myself a very complex question: why?
As I am getting more and more involved with those technologies in a work environment the answer seems to be creeping out of the dark: corporate technologies have a bad habit of trying to overengineer everything (ok, not everything). A problem is not solved by the think -> build algo. No, it involves think -> get in touch with the jargon -> research -> diagram -> more research -> new diagram -> research -> final diagram -> build. Give or take a couple of steps.
While this may be a bit exaggerated, it’s the truth (come on, be fair and admit it :)). The languages used were not built specifically for web development, they were adapted for it. So, what’s up with missing the point? Well, I personally believe that US americans are unable to do so because some people out there in our nation don’t have maps
and I believe that our education like such as in South Africa and the Iraq everywhere like such as– ok, just messing around, woohooo South Carolina!
As I was saying, I believe that these technologies tend not to meet well with the “release early release often” methodology that the more recent web seems to be built upon. I’m not saying that they are bad or anything, it’s just that they take some of that dynamic feel out of web development; everything is just dull software engineering again (I know s/e is not dull and that it’s the only way a long-time reliable system can be built, but let me make my case here), all work and no play. Dynamic languages are a lot more attractive for web development because they allow you to see the results of your work early on; you don’t spend hundreds of hours diagramming on a problem only to come to the conclusion that you took the wrong approach and you need to restart the process.
Sometimes I feel like these technologies are missing the point, which is to build web sites, fast and as reliable as possible given the development timeframe. This is not the plain old OS playground anymore; on the web you need to be fast or perish because if you fail to meet the user’s expectation quickly, people will forget you instantly. They don’t have to go through the hassle of uninstalling your software to get rid of it and for every website or solution launched by your company, be sure that there’s another one built by a rival company ready to snatch your user base the instant you fail to meet up with the previously said expectations.
I used to ask myself how come since Java and ASP.NET are considered to be very reliable technologies most of the jobs offered in web development are for dynamic languages such as Ruby, Python, PHP.
I feel like the answer draws closer.
