The writing is on the wall. If you're not learning more JavaScript, you're going to get left behind.
Does that mean that you wont be able to get gigs? Certainly not. It just means that the greatest level of innovation seems to be happening in JavaScript land. Let me tell you a story...
Once upon a time, in a computer generation far far away, ECMA Script was a scripting language in it's infancy. Something designed to make life developing in a browser just a little easier. Java came along and was getting popular about the same time. So ECMA Script jumped on the band wagon and branded itself JavaScript! That helped it gain a little popularity. Enough to hold it's own in the browser space.
Many hesitated to use this JavaScripty thing because it was considered unapproachable or too difficult to bother with, because every browser implemented their core functions just a little bit differently. Enough to make it difficult to make sure that every browser would behave similarly.
Then, in come the standardized libraries. This was the beginning of a revolution. It was when people began to realize that JavaScript wasn't about writing messy code in one huge file that barely managed to work. People started innovating. Creating their own way of interacting with each individual browser, splitting up their scripting files in to more manageable chunks, and so forth.
That was the tipping point. When people realized that this somewhat abnormal functional language could be used to actually do a lot of very powerful things like AJAX, browser animation and more. What is more, it's possibly the most popular language out there that has many of it's foundations coming right out of the LISP playbook. I digress, anyway, that was about the same time that big browser companies began to take notice and start optimizing their JavaScripting engines (really, we have Chrome to thank for the JavaScript engine optimization war). What is more, people started thinking about the best ways to utilize these new capabilities and a whole new era of libraries were born- ExtJS, SproutCore, Backbone, and so many more. These have all been used to push the browser in to new levels of near-desktop application styles and design. Who would have guessed that JavaScript would become the glue of the browser?
What's more, it doesn't stop with the browser. Nothing as solid as V8 can stay in one place. V8 is the JavaScript browser built by Google for their Chrome web browser. The thing is.. it was fast. Really, really fast. Why couldn't the server side also benefit from such a fast engine? The answer is.. it could! NodeJS was born. Not the first JavaScript interpreter to show up on scene, but definitely the one to catch on. Including package management in a similar way to what is done in the Ruby community.
This is a new way of working- "Event" based programming. It's an upstart. A powerful one. People have started to realize just how much idle processor time they have, and how much could be utilized by not constantly having a blocking thread. It's like the idea of not using transactions for databases. The first time you see it, it just doesn't make any sense. You have to put the time and effort in to understanding it before you can utilize it's power.
I don't think it's a unfair of me to say- JavaScript is the glue that holds a fair portion of the internet together. As we move forward, I can say with some level of confidence that JavaScript will continue to take a larger role in server and client web application development.
2012-03-21
2012-03-16
Three Months with Extreme Programming
With nearly a decade of enterprise development experience under my belt, I have finally had a brush with Extreme Programming. For those that don't know what that is, it is a form of Agile development that has a few very specific qualities that differentiate it from all the others. Most notably from a development perspective, pair programming on all coding (which turns out to be- all day, every day). There is a concept of heartbeat and rhythm, but those are shared with many other Agile shops.
My focus for this review is going to be regarding the results of pair programming each and every day.
The Short Term Effects
Each day starts out by figuring out who is going to be pairing with whom. Their are differing ways of dealing with this, but often times it is fairly organic that those that show up first, pair together. This creates something of an uneven pairing process (if you're trying to keep the pair partners fluid and changing). It's important to use some kind of a pairing chart reminder if this ends up happening. To force a change in the pair mid-day in order to keep people working with fresh pairs. It's hard to consistently work with the same people.
Every developer on the project has exposure to every system that is under development. In theory this leads to no one person ending up the guru of a particular system. That effective knowledge transfer is a highly sought after commodity in the enterprise world.
As a byproduct of such close quarters, that it generates a lot of communication and design chatter. It's not about just throwing code down immediately. Each line of code costs more, but has a higher level of design consideration. It's argued that this is where time is actually accelerated. Because less code that isn't needed never gets written.
Meetings become more difficult because it becomes necessary to re-figure out the pairs after each meeting, and usually there is a need for a fair amount of breaks for each individual.
The Long Term Effects
Burn out becomes a serious problem. When everyone is operating at 100% capacity on an ongoing basis, and going home completely wiped, that creates a certain amount of reduced morale. In turn, that ends up requiring some kind of mitigation in one way or another. Whether that's through some form of a 20% rule (where one day of the week is spent separately doing other things), or something else, it is necessary. It is as if you're constantly operating a power reactor at the red line. Eventually, it's going to have blow back, and it's going to need a serious overhaul.
Due to burn out and the high level of collaboration, this can lead to something of a person-that-writes-the-code and person-that-reads-the-code (because they need a break). That can also result due to one person having a more domineering personality, or the other a more submissive one. That can have very detrimental effect on the team as a whole.
That isn't to say that it's all bad. Far from it. The shared ownership of the codebase, greater all around knowledge and potential tight bonds of the team. Those all make for a pretty winning scenario.
What is the net result?
Balancing on the head of a razor is extremely difficult. The more people involved, the harder it becomes.
Continuous collaboration. Burnout from being overworked.
Efficient knowledge transfer. Tight working conditions.
Higher code quality. Slower coding rate.
Domineering personalities vs submissive ones.
It's about the trade offs and being honest with yourself. I found that this particular style of development was not for me. That is not to say that I don't think it has many positives. It just requires the right personalities, a lot of commitment, everyone buying in, and willingness to constantly evolve the team. Many developers are not right for this style. Me? I found myself anxious constantly. I have my own rhythm when coding, and I don't like having to artificially hold that rhythm in check. It doesn't feel natural.
Those that can do it have my respect. It's a strong way to get the job done, and get it done right.
My focus for this review is going to be regarding the results of pair programming each and every day.
The Short Term Effects
Each day starts out by figuring out who is going to be pairing with whom. Their are differing ways of dealing with this, but often times it is fairly organic that those that show up first, pair together. This creates something of an uneven pairing process (if you're trying to keep the pair partners fluid and changing). It's important to use some kind of a pairing chart reminder if this ends up happening. To force a change in the pair mid-day in order to keep people working with fresh pairs. It's hard to consistently work with the same people.
Every developer on the project has exposure to every system that is under development. In theory this leads to no one person ending up the guru of a particular system. That effective knowledge transfer is a highly sought after commodity in the enterprise world.
As a byproduct of such close quarters, that it generates a lot of communication and design chatter. It's not about just throwing code down immediately. Each line of code costs more, but has a higher level of design consideration. It's argued that this is where time is actually accelerated. Because less code that isn't needed never gets written.
Meetings become more difficult because it becomes necessary to re-figure out the pairs after each meeting, and usually there is a need for a fair amount of breaks for each individual.
The Long Term Effects
Burn out becomes a serious problem. When everyone is operating at 100% capacity on an ongoing basis, and going home completely wiped, that creates a certain amount of reduced morale. In turn, that ends up requiring some kind of mitigation in one way or another. Whether that's through some form of a 20% rule (where one day of the week is spent separately doing other things), or something else, it is necessary. It is as if you're constantly operating a power reactor at the red line. Eventually, it's going to have blow back, and it's going to need a serious overhaul.
Due to burn out and the high level of collaboration, this can lead to something of a person-that-writes-the-code and person-that-reads-the-code (because they need a break). That can also result due to one person having a more domineering personality, or the other a more submissive one. That can have very detrimental effect on the team as a whole.
That isn't to say that it's all bad. Far from it. The shared ownership of the codebase, greater all around knowledge and potential tight bonds of the team. Those all make for a pretty winning scenario.
What is the net result?
Balancing on the head of a razor is extremely difficult. The more people involved, the harder it becomes.
Continuous collaboration. Burnout from being overworked.
Efficient knowledge transfer. Tight working conditions.
Higher code quality. Slower coding rate.
Domineering personalities vs submissive ones.
It's about the trade offs and being honest with yourself. I found that this particular style of development was not for me. That is not to say that I don't think it has many positives. It just requires the right personalities, a lot of commitment, everyone buying in, and willingness to constantly evolve the team. Many developers are not right for this style. Me? I found myself anxious constantly. I have my own rhythm when coding, and I don't like having to artificially hold that rhythm in check. It doesn't feel natural.
Those that can do it have my respect. It's a strong way to get the job done, and get it done right.
Subscribe to:
Posts (Atom)