Inception of an Application

As software developers, we're consistently asked to 'just build this thing'. I used to find it somewhat flattering that people would believe that I could help them realize their dreams. After years of talking to people about their ideas, and occasionally offering to help out, I came to a much different understanding. It was less flattering, and more frustrating. It's like asking a construction worker if they would build you a high rise. Maybe that'd be nice, but it's a dream. Without backing, it's like being asked to help them win the lottery. The person asking often just doesn't have any conception of the time and will that it takes to bring about an application. So I thought I would write this introduction to what it takes to get a developer interested in building your application, and why the magnitude of the word 'just' is staggering.

While this first post is more clearly aimed towards the person that is new to the SDLC (software development life cycle), it may have some insightful points for the seasoned programmer that isn't accustomed to reflecting on why they should build their own applications. Either way, lets hop right in.

When you feel that stirring that you think you might have an idea for a piece of software, you need to start answering questions about it. Usually before you even bother anyone else with it. It needs to become an object in your own mind that you can spend time carefully questioning and scrutinizing. Turning over each facet and understanding what you have, even before you bring it to other peoples attention. These five questions should lay a solid groundwork for refining the startling clarity that you will need:

1. What is it that you want? Hint: This answer should be personal, and probably long form.
2. Who is your audience? Apps are not all that different from books.
1. Why will the audience care? 
2. How will it save them time, or improve their process?
   Remember: People wont use your software if it doesn't improve their life in some way.
3. Why is it worth doing, what is going to make it be amazing? Don't be circumspect.
4. Where will the motivation come from? For you and anyone else working the project.

These are reflective questions, not meant for easy answers. If you believe that you have found an easy answer, then you probably need to go back to the drawing board and keep brainstorming. These questions should generate a lot of thoughts as you really start to understand your idea. Paragraphs worth, perhaps. Once you feel you have a solid understanding, then the next step is to distill these answers down to a 5-15 second elevator pitch. Something reasonably easy and quick for your target audience to understand, but leaves them wanting more. This is not the pitch you should use on developers. Most developers have a finely tuned BS-o-meter, and wont be interested in a sales pitch.

Once you're comfortable that you have a solid pitch, then you should move on to keep questioning your idea with deeper, more incisive questions. While these aren't prescriptive, they're a great starting point for things that you'll definitely need to understand:

• Who is your audience? Dig in to them. If you think you have multiple audiences, make sure you go over them all.
• Why do they care? What are their motivations?
• Why will they use your software daily?
• How is your idea better than your competition? And don't fall in the pit of 'There's nobody else doing this'. There's always someone providing some kind of competition.
• Will this software have a revenue stream?
  If yes (and 99% of the time, if you're not the developer, it should be yes): 
• Where from? Sales? Ads? Grants?
• Why will they give you their hard earned money?
• How much will it generate? And don't be coy.
• Is that worth up-keeping for at least 7 years? Think maintenance and return on investment.
If no:
• Where there is no money, there darn well better be a strong motivator. What is it?
• How will you host and maintain the software if you have no money?
• How will you get developers interested, and keep their attention?
• Are you really sure it's worth keeping up for at least 7 years?
• When do you want it by? 
• Are you going to need resources/money to develop it? 
• Where are those resources going to come from?
• Finally, and most importantly, how will you know when you have your desired software?

These are just stepping stones to get you moving in the right direction at a high level. They're thinking points that will assist you in figuring out what your starting point looks like, and deciding if you are willing to be in it for the long term, and if you'll be able to actually get money out of your product.

If you've made it through this entire process, only then should you really think about involving a developer. Understand that you're talking to someone that can help you realize your dream, but don't imagine you're asking for a dog house, when you're actually asking for a high rise, and remember that they're not likely to build a dog house for free, much less a high rise.

Assembled Best Practices for Software Development

I've been curating a list of my favored practices for some time now. These ideas have come from a variety of sources (books, blogs, coworkers, myself, etc.). These make up some of the best ideas and practices that I have seen in software services. There are a whole lot more that I could talk about, but these are the most important that I think everyone that works in software development should be familiar with. Without further ado:

Understand the foundation. This can be one of the most glaringly obvious, yet oft overlooked, points of an application. Every application has a goal; Something that it aims to do better than anyone else. Generally, that goal leads towards two or three core competencies that the whole platform will revolve around. Make sure you know what those competencies are, and don't ever sell them out, or outsource them. Your evenings and weekends depend on it.

Features are like pets. They're fun! But, they have to be groomed, cared for, and carefully maintained. As such, like pets, you should be very careful about which ones you adopt. Whenever someone says, "We should add.." always start with "no". Make any non-core feature work to be in your application.

Scratch your own itch. The next big thing is a lie, and doesn't deserve your attention. Make something that saves you time, and makes your life better. There will always be people trying to figure out how to force the next application to blow up in to something big. Instead, just figure out what your itch is, and scratch it.

Always Be Shippin'. Too many projects die before they even get off the ground. Figure out what the minimum viable set of features are, and then ship it as quickly as possible. After that, iterate on the design, and make sure you get it in front of your (preferably paying) customers, right away! They'll love you all the more for seeing your software evolve in front of them. Speaking of which:

Love your audience. Your software is nothing without your customers. Focus on their needs and collaborating with them, more than the amount of money, or the contracts that they bring in. When they give you information, respond to it. The most important lesson of sales is to remember this one simple truth: People don't buy a product, they buy an emotion. Make them feel good over and over, and you'll have a customer for life.
 
The customer always believes they are right. But, they're probably not. That's right. Conventional wisdom is wrong. That doesn't mean you treat them as if they're addled. On the contrary. You should always treat your customers with dignity, and respect, if not admiration. Yet, even when you do that, you should help them understand why your software works the way it does, and don't let them dictate terms that will lead you in to a feature haze. That way only leads to heartbreak. Listen to your customer, ask pointed questions, and act only when it is in the best interest of your entire audience. Never become myopic, as that always has an effect on the picture as a whole.

Build simple systems. Some will find it frustrating or condescending, but building three ways to do the same thing in your system doesn't make you nicer, it makes your system more obtuse. Find one way to make your system do the best possible work, and make it as intuitive as you possibly can.

Estimates are pure guesswork. Don't fall in to the trap if you can help it.  Keep shipping features as you are able. If someone makes you guess how long it will take you to implement a particular feature, imagine how long it will take, then weight that by somewhere between 1.5 to 5 times that number, depending entirely on your own personal expertise and the complexity of the system at hand. If you think something that you're not very familiar with will take you a day and you're dealing with a complex system, don't feel bad about saying five days. If it's something you're very comfortable with it's not complex at all, and you think it will take two hours, go with three. The key is this: Always under promise and over deliver. People may think you're daft when you guess five days, but they'll think you're a miracle worker when you deliver it in two, instead of grumbling about it taking twice as long as one.

Remember these three things:

1. There are things that you know that you know.
2. There are things that you know that you don't know.
3. There are things that you don't know that you don't know.

That last category is the largest of the three, guaranteed.

Finally, the best way to learn is to practice, scrutinize, adjust, and repeat. Don't just keep doing same thing that you've always done, else you'll always get what you've always got.

Code on. 

How Java and Ruby made me a better Node developer

Herein is a partial recounting of the bits and bobs that I have learned passing through different programming languages. Principles and processes that I found useful, and not so. It is by no means a complete recounting, but rather meant to help people understand why it's so important to try new things, even when you think you've 'got it down'. How each culture brings new and innovative ideas that can better your code! Onward...

Just shy of a decade with Java

There are many things to be said in favor or against Java. While I personally have no plans of returning to the language in the mid-term future, I learned many things from it and the connected community.

The Java Virtual Machine is a rock. Meaning, it is a very suitable foundation upon which to build the next generation of languages, much the same as C is. It allows highly portable code to be crafted such that it can be highly performant on just about any system that the JVM runs on, in languages (groovy, scala, clojure, jruby, et plus..) that are much more terse and flexible.

Everything in Java-land is configurable. This can be both a boon and a bane. Many Java libraries take their configurability to the point of absurdity, which in turn leads to codebase bloat. Spring is a fantastic example of this. It started off as a great DI platform, and ended up with nearly a J2EE level of complexity and in-and-of itself requires hundreds of megabytes of space on disk, not even to speak of once it gets in to memory. It is not desirable that every library should cover every possible option.

The Java community has a love for design patterns. I was first exposed to many useful patterns that I still use in other languages while I was in Java, here are a few that I still use quite regularly: MVC (or rather, variants thereof), Observer, Messaging, Facade, Factory, and Flyweight. Many of the others still apply, but aren't as useful when you have a greater syntactic flexibility. Realizing that these patterns are available to me has been a great help. When I am trying to reason through particularly difficult problems, I can fall back on some of these great patterns and find possible solutions. Unfortunately, the Java community takes this to an unhealthy level in a lot of cases. They get bogged down in talking about patterns instead of solutions. As martial arts masters say, first you have to learn how to do it, then you have to unlearn how to do it, and just do it.

Document all the things. When you work with so many highly configurable pieces of code, you have to make sure you know exactly how to make those libraries perform as you wish. The Java community is fantastic at generating vast quantities of documentation. There is a lot of white noise when you going looking for a specific problem that you have, but more likely than not, someone has your problem documented, somewhere. You just have to dig hard enough to find it. There are many communities that could learn from this approach.

Boilerplate is bad, mm'kay? Strongly typed languages require lots of it, no matter how you slice the problem. Particularly when trying to encapsulate absolutely everything. My take away from this is that boilerplate, while sometimes necessary, is an undesirable. If you find yourself constantly writing the same pieces of syntax over and over, you're probably just wasting your time and making your code more complex. Sometimes the solution is to refactor. Sometimes you need to re-evaluate the tools that you're using.

No conversation about Java would be complete without mention of their dogmatism. This was one of my greatest take aways from the Java community: Don't adhere to dogma. More than that, don't listen to appeals to authority. Just because it's writ in an RFC somewhere, doesn't make it the right way to do something. The Java culture takes their 'thou shalts' to an unhealthy level, and they end up writing massive amounts of code in order to prove their adherence.

Two years in Ruby

Ruby was built with developer happiness and ease of use in mind. It is an object oriented language that inherits a lot of its thought processes from Smalltalk. It was my first completely object oriented language, and I must admit that I found its terseness to be a breath of fresh air when I first joined the world, after so long in Java. When I was first coding for the web using Perl and PHP, and then went to Java, I thought for a very long time that it was going to be almost impossible to go back to a dynamic language, due to how poorly written "all dynamic code" was. Due to my experiences with Perl and PHP. Oh how wrong I was, but it took me a good amount of my own personal time, and jumping off the cliff in to enterprise Ruby to truly find out how "ready for prime time" that these new dynamic languages have become!

While I was not originally exposed to the Pareto principle ("80/20 rule") in Ruby, it was the first time that I saw many libraries trying to follow its advice. While controversial to many people, I saw this work out very well for a lot of cases. Take ActiveRecord for example. That library makes it very easy to do basic database queries against any number of relational databases, but if you need to do something more specific with a database, like call a stored procedure, you can just use the connection directly. Rather than them trying to encapsulate that functionality somehow.

Convention over configuration. A phrase that seems to have come directly from the Ruby community as far as I can tell. Those involved in Ruby still build some fairly large libraries (though nothing alongside the monolithic ones that are in Java), but they provide sane defaults. A good portion of the time, even if you're using a fairly impressive sized library, you can start with just bringing it in and using the default settings that it provides. This language was the first that I had seen that provided these sane defaults that you didn't have to shepherd and tweak to get just right.

Keeping it Simple and Stupid is a mantra for the Ruby community. That's where a lot of the innovation that people hear about from Ruby-land comes from. Don't overbuild. As DHH said, Rails is omakase. Don't like ActiveRecord? Don't use it. Need to kick some processing out of your web worker thread? Great, put it on a queue somewhere for a worker to pick up- but don't overbuild that queue. You should have sane defaults so that you can get a worker on that queue almost immediately. Anything else is overbuild and waste of time.

Two very important acronyms: DRY (Don't Repeat Yourself) and YAGNI (You Aint Gunna Need It). These two are mantras that I find myself repeating constantly while I'm programming. "Do I need to be able to do that with this piece of code? ..Nope!" And, when I start to copy and paste a set of code, or start retyping code that I know is elsewhere, I immediately stop myself and start refactoring so that I only have one set of code performing any particular function. I can't even begin to recount how many times this has saved my bacon when hotfixing applications.

Rails Style: "Skinny controller, fat model". This means that you should put your business logic, or the logic that actually performs changes, in the model. The controller shouldn't be overbuilt, it should only contain enough code to tell the model what to do with itself, and then pass the information back up to the client. I think that this doesn't go far enough some times. There are usually opportunities to improve even further on this during fairly complex processes. Rather than expanding a model in to quite large proportions, I occasionally take a cue from the Java land and write up a service layer instead. So that you're not bloating your controller or your model to an unmanageable level.

While the Ruby culture is not quite as dogmatic as the Java culture, they still definitely believe there is a right way and a wrong way to build your applications. Particularly if you live in Rails-land, rather than one of the subcultures (Padrino/Sinatra, for example). Still, the Ruby culture is more palatable and less stogy than the Java one in my estimation.

What's more: The Ruby culture taught me that development can be fun again. I blame that expressly on the fact that so few "paycheck developers" spend their evenings learning Ruby, so it is a group of enthusiasts instead of people that are looking for their next gig.

A year of Node

My introduction to Node came when I started using it regularly as tooling, which I do believe is how it is getting its induction in to a lot of development groups! Whether it is setting up an asset pipeline (grunt/gulp), or giving you a foundation for your next web application (yeoman), or managing your front end javascript dependencies (bower), there are a lot of uses for Node without even utilizing it as a primary language. That's a pretty big win. Once somethings starts to feel familiar, you can't help but start be curious about how more of it works. Eventually, I decided to take the plunge. I'm glad I did, despite some of the pundits that speak of Node's insufficiencies.

So far in my time spent in Node, there are two big things that I have taken away. One of which I've mildly hinted at from the Java and Ruby sections: Modularity. Ruby still has some fairly large large stacks that it requires one to use. While Rails is not one monolithic framework, but a collection of fairly large frameworks, it is still nearly 200mb in memory when it is first loaded. While memory is cheap, and disk is too, I still don't believe that relieves us developers from paying attention to those numbers.  When I first built an express application with Node and it used less than fifty megabytes from the get go, I knew I was hooked. Sure, there are some lighter weight frameworks in Ruby and Java, but that's not really how their communities think. The strongest and most active communities in Node revolve around the ExpressJS foundation. The primary application that I support today is less than 150mb with all code, in memory. The largest node app that I maintain doesn't go over 300mb in memory until it starts taking requests. I remember one java gig that I took, and they had a server with 32gb of memory for me on my first day, because the application itself took up more than 8gb in memory... I still look back and shake my head.

Asynchrony is pure win, but has its trade offs. It comes at the cost of comprehension. It can be harder for the developer to reason through, when nearly everything is an event (everyone that has spent much time in JavaScript has heard of "Callback Hell"). Despite that, there are many advantages of having your code being non-blocking. The scalability characteristics for any program that has to spend any time in wait cycles (and any program that accesses a database spends lots and lots of time waiting) is losing a lot of computer cycles just sitting and waiting for that response. Node takes full advantages of that time spent waiting to do other things, instead of making them wait in line. This is primarily achieved with the heavy use of streams. Any non-trivial application will eventually end up doing some work with them. It'll probably bend your mind a bit at first, but eventually you'll see the light At this point, I'd have a really hard time justifying going to an "IO Blocking" language again, having seen the ease with which Node can scale.

And.... That's a Wrap!

Phew! That was quite a bit! I hope you found this review interesting, or at least a bit insightful. Feel free to leave me a comment either way, I'd like to hear what you think. Either way, I would encourage you to not get too comfortable where you're at. Keep pushing the boundaries. Keep innovating. Because that is what being a coder is all about.

Getting Uncomfortable: Three Years in Retrospect

It's been years since I've written in this blog, yet I feel that many of the things herein have bared out to show what I was originally speaking of. Particularly with regards to my predictions of CoffeeScript. There are more options than ever for writing JavaScript with syntactic sugar: CoffeeScript, Dart, TypeScript... Pretty impressive for a dynamic language!

It can be a little scary jumping in to a new pool of knowledge, even if some of your old knowledge still applies. That's how I felt when I left behind Java, and dove in to the wide world of Ruby, and even more so later when I dove in to Node.

Minneapolis is not a "technologically innovative" part of the country. The majority of developers that live in this area are mired in technologies that are "safe" or "proven" rather than pushing the boundaries. Though I'm not sure Ruby counts as pushing the boundaries, considering that it has been around since 1994, and Rails has been under active development since 2004. Somehow that still qualifies as "new" technology in a lot of peoples eyes. I can only imagine what they would think of those writing applications in Node, which was first released in 2009! 

Somewhere along the line there was a shift in technology culture. I can't imagine anyone that was in technology during the 70s and 80s having the same thought process. They were chomping at the bit to push the boundaries of what can and should be done. We wouldn't be where we are today without those innovations. Sure, not everyone can be on the 'wave' of technology. There have to be many holding down the old tech, keeping it all under control. The change has become fairly clear. What's more, it's surprising how many greenfield projects end up choosing Java or .Net as their building blocks. Because it's what they have used for more than a decade.

With that as background, here is what I can tell you about living in the dynamic language world:

1. Don't hesitate to use Ruby or Node for your next production application. If Github, New Relic, 37Signals, and Ravelry can scale Ruby, so can you. If Paypal and Walmart can scale Node, so can you.
2. There is massive scalability with some of the new frameworks out there, without having to stand on your head while holding three blocks with your feet. Worry more about your problem domain, and choose tools that help you solve those problems swiftly. Speaking of which:
3. Time has a cost. It's called opportunity. When you spend time writing an application 'the only way you know,' and that way takes a factor of 5 times longer to build the application, you need to find a new way. Give your idea life, don't let it flounder in a quagmire of "we've always done it this way".
4. Embrace new ways of thinking. Every time I have adopted a new language, it has brought new thought patterns to light, which in turn makes my code better, and thus my end product stronger. 

Don't be skeptical of new technology, embrace it. Try it. Extend it. How do you think the Java and .Net platforms grew to be the size they are? Because people with their own visions were constantly hacking on them. That's the way they managed to mold the subculture. Maybe you don't like what Ruby brings to the table. That's understandable, but standing still is not. Try Python instead! Too mainstream? Sure! Try Node! The asynchrony will make your head spin. JavaScript not your thing? Okay, but I think you're just making excuses now: Try one of these powerful languages: Elixir, Erlang, Go, or Rust! It's an exciting time for developers. There are so many new ways to build massively scalable applications. Take up the challenge! Don't eschew the new for the old. Get out of your comfort zone. See what's out there. 

You will be better off for it. Even if you never deploy a production app with it.

Stay tuned for my next post: How Java and Ruby made me a better Node developer.

CoffeeScript Is the future of JavaScript

What is CoffeeScript? It's an abstraction on top of JavaScript that makes your code more maintainable, readable and beautiful. Your CoffeeScript compiles down to JavaScript that runs as fast (if not faster) than your otherwise hand coded JavaScript would. A bonus is that it runs through JSLint error-free.

Why do I think that CoffeeScript will take over the landscape of JavaScript? Simple. Because it's committee-free. There is no major group that controls it. It's a simple abstraction on top of current standards that forces you to write sane JavaScript (almost as if it came out of the book JavaScript, The Good Parts).

JavaScript has been a nearly quality-control-less language since the beginning. There have been some great strides towards forcing better quality on JavaScript, but most of them are trying to drag other paradigms in to the JavaScript world, rather than forcing good JavaScript practices from the very beginning. Things such as appropriate scoping have often alluded even strong JavaScript developers for a long time. With the advent of CoffeeScript, it makes JavaScript "feel" a little bit more like a fully featured object oriented language.

"What about the next version of ECMAScript? Wont that fix a lot of the problems?"

Where is it? I still don't see even a shell implementation in one of the latest and greatest modern browsers. Moreover, when can we use it? I'm still coding to IE6 specifications on occasion. How long is an acceptable grace period before I can just start disregarding the previous version of ECMAScript?

The answer is here and now. Something on top of JavaScript to enforce standards and make things more readable. Yes, it's syntactic sugar on top of JavaScript. That's a good thing. JavaScript is half-baked and half-readable- CoffeeScript will make life easier while we're waiting for the next big script level to get to where we can use it regularly (which I'm guessing at somewhere around 2016).

The JavaScript Revolution

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.

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.