Skip to content

Five risks of solo programming

August 15, 2008 by Artem Marchenko

Woman hiking a slot canyon in the Narrows, Zion National Park  
Pair programming is one of the most debated practices of the Extreme Programming. Historically, programming used to be a solitary activity that required high concentration and even isolation. The best programmers know how to get into the metal state called "flow" or "zone", in which the undisturbed mind is able to efficiently focus on the code and make highly creative and efficient design decisions.

While "zone" is indeed highly valuable and learning how to deepen into zone as a pair might be more difficult, than learning how to get into flow alone, the truth is that despite the comfort of the long time status quo, solo programming is just too risky and in the end might cost quite some more money for the company. There are many risks of solo programming, here are the top five that come to my mind.

High defect rate

This is the most obvious risk. Human beings are not the magicians and whatever accurate you are trying to be, occasional typos, misunderstanding of requirements and just mistakes are inevitable. Solo programmers fight these mistakes with the help of careful planning, code reviews and various code analysis tools. These activities are definitely useful, but no code review performed after the fact can compare to the continuous code review performed during the act of coding, no amount of careful planning can compare to pairing with the customer, business analyst or tester while working on his requirements.

Pair programming is not a silver bullet, but it is just too risky to assume that a single person can prevent the creation of as many bugs as a pair can.

Distractions that force you out of the zone

Average office worker is interrupted every 11 minutes. No surprise it is so difficult for a programmer to stay in the "zone" and get to the creative and efficient code design. It is not so easy to interrupt the pair working as a team. For people walking through the same office, it is mentally more difficult to dare to interrupt the whole team, pair often shuts down the "individual electronic interrupters" such as the email client that tends to shout about the new message every now and then. Then even if the pair has to be interrupted, often just one person can go deal with the important request and leave the second one in the "zone" to join him after the distraction reason has been resolved.

Pair programming is not a silver bullet, it is just to risky to assume that solo programmers can be as resistant to the external distraction as a pair can be.

Low focus and discipline

Programmers are quite disciplined people, but sometimes there are just very funny commercials shown on YouTube or cool, but irrelevant [to the moment] articles published on a popular web site. These reasons for interruption aren't that bad on their own, after all you cannot creatively code 8 hours in a row. However when this kind of temptation goes out of control, it adds yet another source of distraction. When working in pair, each party naturally feels stronger commitment to the common goal and people can go after the purely private goals after the pairing time slot is over.

Pair programming is not a silver bullet, it is just too risky to assume that a solo programmer can resist the discipline-breaking temptation as efficiently as a pair can.

Low incentive to adhere to common practices

When the deadline is around the corner, it is easy to forget to care about the quality of unit tests, to perform architecture analysis, to verify that the variable names are according to the organizational standards, etc., etc. It is not that easy to admit this in front of your pair. Vice versa, it is much easier to get enough courage to tell the management that a task is too big or to tell your pair, that you just don't know how to apply the certain practice efficiently.

Pair programming is not a silver bullet, it is just too risky to assume that it is as easy for a solo programmer to adhere to common practices as it is for a pair.

Slow learning

Any person entering a team whether he is a seasoned developer or just graduated rookie needs time to learn the team standards, ways of working and the code itself. Solo learning can take months and a shy person might still be not aware of a particular tool usage. Pair programming with a mentor or mentors significantly reduces the amount of time needed to learn the subject area, code and to pick up the team habits.

Pair programming is not a silver bullet, it is just too risky to assume that a solo programmer can learn as quickly as if he was paired with a seasoned team member.

Your risks

What are the biggest risks of solo programming in your opinion? What would you add to the list?

About the Author: As the Editor-in-Chief for AgileSoftwareDevelopment.com, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem

Comments

Uhm.. conjecture

August 15, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1774

Just because you can't hack it as a lone wolf doesn't mean that no one can..

Commercially Naive

August 15, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1776

There is one basic problem with pair programming: Two people working together cannot produce as much commercial output as one person. Commercial realities, especially when heading into recession, are more important than the items you list above.

1. You say that there is a higher defect rate for single programmers. I would like to see the evidence of this. Possibly there would be a 75% higher defect _count_ if the two people working together but not paired were also producing 75% more output?

2. This is pure bunk. The developer is not the average office worker. If, as a manager, you allow this type of interruption then you are an idiot, particularly if your team is large enough to permit pairing.

3. Low focus and discipline. Are you kidding? Good developer are amongst the most focussed people I know. However, everyone needs a break a few times during the day and, from my experience, the breaks are longer when there are two people playing on the Internet together.

4. I don't know how to answer this one. It seems like an addition because you were struggling to hit five reasons.

5. This is almost 4 again. However, I see no difference between the solution provided by pairing or a similar solution provided by mentoring within a team. In fact, a pairing with another developer with bad habits could be more damaging than a general concensus with a team.

This article is arse gravy of the worst variety.

Your last two points

August 15, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1777

I agree with most of your article .. although I think your last two points ( low incentive to adhere to best practices and slower rate of learning going solo ) are probably your best.

The guy who titled his post "commercially naive" is absolutely mistaken when he says that a pair cannot produce more commercial output than a solo developer. It may look that way at first .. but not later when the pair has a cleaner design and less insidious bugs to try and dig out later. Over the entire development cycle, the pair catches up and wins the "output" race.

Good post.

Commercially Naive

August 15, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1778

In response to the "Your last two points" poster.

Where do you get your data from? I would agree that *A* pair can produce more than *A* solo developer. However, my data shows that *A* pair produces substantially less that *TWO* solo developers, particularly if those solo developers are on a team.

Yes, occasionally a pair will spot an error as it is typed. However, these tend to be typos and simple errors. The more complex errors that can creep into software are probably found more quickly by a pair than a solo programmer. However, twice as quickly? I think not.

Personally I believe that pair programming is one of those fads that some people (though not the post's author I note) believe is a magic bullet. I would fully expect it to be replaced shortly as most other things have been.

I would certainly be getting concerned by the world economic climate if I were a pair programmer right now. I know of several companies that are already slashing their developer numbers and I think that many others will follow suit, possibly by halving those pairs...

Data

August 16, 2008 by Artem, 6 years 6 weeks ago
Comment id: 1781

I have a bit of a mental problem replying to Anonymous commenters, especially when you don't know whether these were several people or a single person (maybe I should remove the default "anonymous" name), but in the end I guess skeptics do have a point in requesting the hard data. My personal beliefs and observations might be interesting for some people, but backing them up with the decent study results would make the debate more focused on discussing the ways for mitigating the risks, rather than on discussing whether the risks are real.

I will definitely search the research part of the web and will try proving (or disproving) at least some of these risks some time soon.

Commercially Naive

August 16, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1782

One commenter in this case (for my previous two comments).

I would certainly like to see hard data. The evidence I have gathered through monitoring the teams in our business, which has recently merged and contains an agile group (TDD, pair-programming, etc.) and a non-agile group. Over the past eight months, I have noticed the following:

The agile group produces less defects in the same period of time. However, the non-agile group produces far more software. This seems to give roughly the same number of defects per "unit" of code.

The non-agile team makes more money per developer. Substantially more in fact, given figures ofapproximately 125% more per person is terms of monetary value. That is, for every Euro that the agile team make in turnover (not profit), the non-agile team makes 2,25 Euro.

I have seen that the agile team are able to begin coding more quickly than the non-agile team, who prefer big upfront design. For small developments, the agile team are able to respond more quickly but for large software, the agile team tend to flounder and the non-agile team respond more quickly and with better accuracy. They believe this is due to the solid, rather than evolved, design that they have and due to this design being available on paper where the non-agile team have less documented design.

The upshot is that in the current economic climate, we are looking to make redundancies. It is looking likely that we will be losing 40 of the 105 developers that we have. It is very likely that most, if not all, of these will be from the agile team because they provide the business with the least value individually.

One last point. I am from the business that had the agile team and I am a huge proponent of the agile manifesto. I have had my eyes opened by coming into contact with the non-agile team from the business that purchase our company and I am now questioning our practices in a commercial environment. I am also part of the manergerial team that will be making the cost-cutting measures, hence the anonimity.

It is a very broad topic and

August 16, 2008 by Artem, 6 years 6 weeks ago
Comment id: 1783

It is a very broad topic and very dependent on the concrete circumstances. Therefore, let me touch just several general points (i.e. generalization of my observation of and talks to many teams) in no particular order.

Certainly, how well team is able to embrace agile is very dependent on a lot of factors. In particular there are many ways to do pair programming the wrong way. Some people are even "chemically incompatible" and cannot program together.

It is interesting to hear that you are telling about the agile team producing less defects, but you don't tell whether the defect rate decreases over time. Agile principles call for continuous improvement and good teams (with good coaches) improve over time decreasing the defect rate and improving velocity.

In my opinion Agile methods (or to be precise, the management level of them) aren't focused on producing more features. It is often a nice side effect, but is mostly that - side effect. what [management level of] agile methods is really about is producing *the right features*. High quality and "donness" of every increment allows for getting the customer feedback early and for adjusting the project direction often. As a result you might build less features (though mature agile teams are typically faster, it just doesn't happen overnight), but these features are exactly what the customer needs, not what he told he wants in the very beginning. Pair programming is just yet another vehicle for producing high quality SW. Whether you need it indeed depends on how much you think the built-in quality is important for your organization.

Of course two solo coders "produce more" than a pair...

August 17, 2008 by Caligula (not verified), 6 years 6 weeks ago
Comment id: 1784

...but at what cost?

There are other issues besides "defect spotting" that must be taken into account, too: having two heads working on architecture issues is almost *always* better than one. Looking ahead to the "hit by a bus" scenario is also invaluable, even if no bus is actually ever involved. The issues spotted are usually of greater import than a simple typo.

Call it cargo-cult as much as you'd like, but taking a narrow view of the benefits is doing a disservice.

Yes, Agile Can Fail

August 17, 2008 by peterstev, 6 years 6 weeks ago
Comment id: 1785

It's nice to be reminded that agile is not a silver bullet, that it can fail. I am wondering why it is failing in this case. How many agile developers are there and how many teams? Were you using Scrum or XP? How do your teams score on the Nokia Test? What impediments have the teams identified and were they able to resolve them? Why is agility considered the reason for the lack of success of the product? What other factors contributed to the lack of success?

I used to hold the 1-programmer-is-best belief....

August 17, 2008 by Anonymous (not verified), 6 years 6 weeks ago
Comment id: 1790

.....no longer. I just finished funding about 1000 hours of work by a single developer. When the work was done, we discussed the solitary effort. The programmer expressed he has no 'sounding board'. We discussed the issue in detail.

Pairing works, small teams work. I now believe the best team size is 3 developers minimum, ideally with 1 tester.

Thought-provoking...

August 17, 2008 by rageh (not verified), 6 years 6 weeks ago
Comment id: 1791

The article and the ensuing comments are thought-provoking. Those of us working as freelancers have no option but to code solo, and it is true that there are occasions when you wish you had a coding partner to discuss complex problems with or ask him to inspect your code to locate those-hard-to-spot bugs. I sometimes spend countless number of hours chasing a bug that in the end turn out to be a simple typo. If you have to de-bug your own code by yourself, you tend to overlook many errors another person would have spotted instantly. That is one of the perils of working solo but it can be overcome.

However, the reason why having pair of programmers are better than one working solo is when you are doing the architectural design. Solo developer may take a longer route to implement the application while someone else can point out a short cut, reducing the number of hours the task takes significantly, not to mention the qualitative improvement of the code. So, as someone commented above, if you are after a quality, hire two people if else go solo and thus reduce overall cost of the project. While two brains working on same problem tend to find answers quicker, the cost to the employer is double. Whether the benefit gained is equally double, I am not so sure.

What researchers say

August 20, 2008 by Artem, 6 years 6 weeks ago
Comment id: 1799

Some scientifically valid evidence on the effect of pair programming can be found in this post

I did Pair programming as a child

January 29, 2009 by Johny (not verified), 5 years 35 weeks ago
Comment id: 2208

Well i think pair programming is a overhyped thing in the later article you told about not prising as as the silver bullet but acutally you do.
First time i did pair Programming in 1991 or something when i modifed the q basic gorilla game together with my little brother. It is just logical if somebody can not solve it alone he might do it with somebody together, or your project manager is telling you 'could you do this part together with your colleague'

In a good Team with a nice culture it happens automatically,
well in a buzzword company where everybody works on hos own and tries to be the supercoolest you can go to your boss and tell him, i am so cool i read about this new supercool hype technique it is called pair programming we should buy a book about it, make an exam and use it for everything.

all arguments can be used in both ways,
1. Defect Rate
well allone you have to care about anything yourself in a pair, maybe the other one could (not) do. "I were not taking care of that issue, i thought you were always taking care of that ?"
2. Distractions
however if there talking 2 persons it is a bit more difficult to distrub them but the chance that one of them is needed is twice as high that one of them is needed.
However maybe forward all codes to a secretary or team assistent would make more sense.

3. Low Focus & Discepline
Well even 2 people can focus on something else like general exchange about the newest post on a site or anything else. The developers discipline will even decrease a lot more if you force him to work together with these ugly other guy who didn´t had a shower and had a lot of garlic sauce last night.

5. Slow Learning
well if somebody is new in a team, it s just some usual thing that u ask other team members, well at well written and documented software you need to ask perhaps less,
of cause it can help you if you look over somebodys shoulder or he over yours,
specially if there is a skill difference you can have benefits on both sites.

Thank you so much for sharing

February 7, 2012 by Anonymous (not verified), 2 years 33 weeks ago
Comment id: 20901

Thank you so much for sharing this great blog.Very inspiring and helpful too.Hope you continue to share more of your ideas.I will definitely love to read. mobile anime streaming

Hi Michael-I'm glad you like

March 2, 2012 by NOnn (not verified), 2 years 30 weeks ago
Comment id: 21113

Hi Michael-
I'm glad you like the post. Yes. I'm sure there are some projects where we can lock things down enough in advance that this hyperspecialized approach could work. Similarly. I suspect that even on a project with high uncertainty. there are some parts we can lock down well enough. For example. we may be doing some highly innovative website but it includes a whole portion of things like generic user account management. Maybe that gets sent off to a variety of hyperspecialists while the novel part of the application is done by an agile team. sosh sans engagement forfait illimite forfait sms illimite forfait mobile internet comparateur forfait bloque rio orange numero rio orange rio sfr rio bouygues rio virgin calcul imc portabilite du numero

However, the reason why

March 10, 2012 by anymous (not verified), 2 years 29 weeks ago
Comment id: 21323

However, the reason why having pair of programmers are better than one working solo is when you are doing the architectural design. Solo developer may take a longer route to implement the application while someone else can point out a short cut, reducing the number of hours the task ilnsflqxd jh gsxagvsih hj nmzaopuio hn frwzfubhf
takes significantly, not to mention the qualitative improvement of the code. So, as someone commented above, if you are after a quality, hire two people if else go solo and thus reduce overall cost of the project. While two brains working on same problem tend to find answers quicker, the cost to the employer is double. Whether the benefit gained is equally double, I am not so sure.

But I'll now acquiesce to

May 22, 2012 by JennyH (not verified), 2 years 18 weeks ago
Comment id: 22290

But I'll now acquiesce to this idiocy and never speak publicly of the ordeal again. We did that plenty of that already at Scottsdale City Council in 2005. Bottomline- I don't know what we could have done any better than we did. Sometimes the good guys don't always win. But I do know that you can't negotiate with a terrorist. Ever. That's one of the prime directives. Once you do. you establish a dangerous precedent. When there is no other option but negotiation. you tell your story before they make you shut up and hope that other people that were in the room to hear it. rio orange

I read a article under the

May 24, 2012 by dvd to iTunes (not verified), 2 years 18 weeks ago
Comment id: 22516

I read a article under the same title some time ago, but this articles quality is much, much better. How you do this..
vob to mp4 mac

online buzness

May 26, 2012 by Maneesh Yadav (not verified), 2 years 18 weeks ago
Comment id: 22550

Thanks Your Post has a lot of great information and it has really helped me alot. Excellent post and wonderful blog, I really like this type of interesting articles keep it u. Rank Page

Thanks for providing recent

May 27, 2012 by Anonymous (not verified), 2 years 18 weeks ago
Comment id: 22574

Thanks for providing recent updates regarding the concern, I look forward to read more.
Theo

I'm glad I found this web

May 27, 2012 by Anonymous (not verified), 2 years 18 weeks ago
Comment id: 22576

I'm glad I found this web site, I couldn't find any knowledge on this matter prior to.Also operate a site and if you are ever interested in doing some visitor writing for me if possible feel free to let me know, im always look for people to check out my web site. thomson catering

Nowadays, finding a high

May 28, 2012 by Maneesh Yadav (not verified), 2 years 17 weeks ago
Comment id: 22601

Nowadays, finding a high quality post is really difficult. I’d like also to thank my friend for giving me the URL of your blog. Hope you appreciate my short comment.high pr link

It is nice to find a site

May 30, 2012 by amitabh (not verified), 2 years 17 weeks ago
Comment id: 22626

It is nice to find a site about my interest. My first visit to your site is been a big help. Thank you for the efforts you been putting on making your site such an interesting and informative place to browse through. I'll be visiting your site again to gather some more valuable information. You truly did a good job...Pagerank Backlinks

this is really nice to

May 30, 2012 by Anonymous (not verified), 2 years 17 weeks ago
Comment id: 22633

this is really nice to read..informative post is very good to read..thanks a lot! cash call

Wow what a Great Information

May 30, 2012 by emoboy (not verified), 2 years 17 weeks ago
Comment id: 22662

Wow what a Great Information about World Day its very nice informative post. thanks for the post. here

I really enjoyed what you had

May 31, 2012 by Mohan12 (not verified), 2 years 17 weeks ago
Comment id: 22690

I really enjoyed what you had to say. Keep going because you definitely bring a new voice to this subject...Agra property

I really enjoyed what you had

June 2, 2012 by Mohan13 (not verified), 2 years 17 weeks ago
Comment id: 22710

I really enjoyed what you had to say. Keep going because you definitely bring a new voice to this subject.Auto Transport Quotes

I just want to let you know

June 3, 2012 by Anonymous (not verified), 2 years 17 weeks ago
Comment id: 22744

I just want to let you know that I just check out your site and I find it very interesting and informative.. loansrated

I think this is an

June 4, 2012 by dasdsd (not verified), 2 years 16 weeks ago
Comment id: 22764

I think this is an informative post and it is very useful and knowledgeable. therefore, I would like to thank you for the efforts you have made in writing this article. why jailbreak iPhone

I really enjoyed reading this

June 5, 2012 by dasdsd (not verified), 2 years 16 weeks ago
Comment id: 22800

I really enjoyed reading this post, big fan. Keep up the good work andplease tell me when can you publish more articles or where can I read more on the subject?
Bedford MA

superhit

June 7, 2012 by kanhaiya (not verified), 2 years 16 weeks ago
Comment id: 22822

I am interested in this topic and would like to find out some more information as my friend need information on this topic. Do you have any other articles about this?Book of ra

Thank you for helping people

June 13, 2012 by Anonymous (not verified), 2 years 15 weeks ago
Comment id: 22886

Thank you for helping people get the information they need. Great stuff as usual. Keep up the great work!!! social profit formula

Nice blog and absolutely

June 27, 2012 by Anonymous (not verified), 2 years 13 weeks ago
Comment id: 23077

Nice blog and absolutely outstanding. You can do something much better but i still say this perfect.Keep trying for the best.
Yours Truely Cap Credit

i am always looking for some

July 1, 2012 by Anonymous (not verified), 2 years 13 weeks ago
Comment id: 23169

i am always looking for some free stuffs over the internet. there are also some companies which gives free samples.
Lots of love Skip

We are student and interested

July 14, 2012 by www.dmaastore.com (not verified), 2 years 11 weeks ago
Comment id: 23336

We are student and interested in purchase dmaa because it can overcome, regarding our health problems. We purchase it from www.dmaastore.com

I am Roger my age is 35 year,

July 15, 2012 by AnTi SpAmO (not verified), 2 years 11 weeks ago
Comment id: 23353

I am Roger my age is 35 year, I am taking 5htp supplement from six month. I found someside effects of 5HTP, I feel stomach related problems included loss of appetite, dizziness, dry mouth, and even headaches.

Wonderful illustrated

July 16, 2012 by Anonymous (not verified), 2 years 10 weeks ago
Comment id: 23365

Wonderful illustrated information. I thank you about that. No doubt it will be very useful for my future projects. Would like to see some other posts on the same subject!
Custom Tee $3.99

Its a great pleasure reading

July 16, 2012 by Anonymous (not verified), 2 years 10 weeks ago
Comment id: 23366

Its a great pleasure reading your post.Its full of information I am looking for and I love to post a comment that "The content of your post is awesome" Great work.
website resources

Thanks for sharing the info,

July 18, 2012 by Anonymous (not verified), 2 years 10 weeks ago
Comment id: 23404

Thanks for sharing the info, keep up the good work going.... I really enjoyed exploring your site. good resource... zuma

I keep learning from your site

July 22, 2012 by Anonymous (not verified), 2 years 10 weeks ago
Comment id: 23469

This is also a very good post which I really enjoyed reading. It is not everyday that I have the possibility to see something like this.
Excellent way you handle the variable.
leather ring binder

I have been checking out a

July 22, 2012 by Anonymousdsasd (not verified), 2 years 10 weeks ago
Comment id: 23473

I have been checking out a few of your stories and i can state pretty good stuff. I will definitely bookmark your blog
drawing apps for iPod

seo earning

August 24, 2012 by seoearning (not verified), 2 years 5 weeks ago
Comment id: 23647

The content of your blog is exactly what I needed.This topic has always fascinated me.
All about seo what is seo | How we can enhance our earning seo tips | seo optimization I really appriciate you for this great job.

nice blog

September 12, 2012 by Amit (not verified), 2 years 2 weeks ago
Comment id: 23829

Thank you. We have to try this. stata help

advantage

September 12, 2012 by yelena (not verified), 2 years 2 weeks ago
Comment id: 23839

For me the main advantage of paired programming is a huge boost in code quality, and is especially helpful when learning an unfamiliar code base. The sum is greater than the parts, and paired code gets the best design and implementation possible.

wordpress developers

Business Broadband Packages

November 21, 2012 by Business Broadband Packages (not verified), 1 year 44 weeks ago
Comment id: 24785

Technology is an obligation to be a part of a Global Village.
business broadband packages

It’s an interesting post and

November 21, 2012 by andrew (not verified), 1 year 44 weeks ago
Comment id: 24788

It’s an interesting post and I like to thank you for providing me a chance to read about the Dropbox integration Module for Drupal. . I really enjoyed each part of it. I want to bookmarked your blog to checkout latest stuff. modern kitchen enhancements

The "Clueless or Clued Up:

November 22, 2012 by Anonymous (not verified), 1 year 44 weeks ago
Comment id: 24832

The "Clueless or Clued Up: Your Right to be informed about contraception" study prepared for World Contraception Day (WCD) reports that the number of young people having unsafe sex with a new partner increased by 111 percent in France, 39 percent in the USA and 19 percent in Britain in the last three years.

bayan giyim-evim şahane-20 dakika izle-chat-20 dakika-evim şahane-evim şahane

That is very interesting

December 13, 2012 by robinisa (not verified), 1 year 41 weeks ago
Comment id: 25137

That is very interesting Smile I love reading and I am always searching for informative information like this. This is exactly what I was looking for. Thanks for sharing this great article'.
cell phone spy software

While "zone" is indeed highly

December 15, 2012 by Dennis Lunding (not verified), 1 year 41 weeks ago
Comment id: 25153

While "zone" is indeed highly valuable and learning how to deepen into zone as a pair might be more difficult, than learning how to get into flow alone, the truth is that despite the comfort of the long time status quo, solo programming is just too risky and in the end might cost quite some more money for the company. There are many risks of solo programming, here are the top five that come to my mind. The Worldtravel Guide

Nice Information.

December 17, 2012 by Aryan (not verified), 1 year 41 weeks ago
Comment id: 25164

Great information you got here. I’ve been reading about this topic for one week now for my papers in school and thank God I found it here in your blog. uniformes ejecutivos

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com