Top 11 #Agile Books and top 3 Information Technology books

I just finished presenting at SDEC and I realized that I did not have a Blog post on my Agile reading list. Many people asked about how to get started on Agile and a list of books that influenced me. In a future post, I will list the practices that I tried first and my success with them. (Somewhat of my personal Agile roadmap)

Without further ado here are my top 11 Agile books that have influenced me and helped me to learn about Agile.

And yes, they are in order! Not in the order they have to be read, but in how much I found them valuable.

1) User Stories Applied – Mike Cohn

2) Agile Estimating and Planning – Mike Cohn

3) Innovation Games – Luke Hohmann

4) Lean Software Development – Tom and Mary Poppendieck

5) Agile Database Techniques – Scott Ambler

6) Art of Lean Software Development – Curt Hibbs

7) Lean-Agile Software Development – Allan Shalloway

8) Test Driven Development – Kent Beck

9) Lean Architecture – James O. Coplien

10) Agile Testing – Lisa Crispin

11) The Art of Agile Development – James Shore

And the top three Information Technology books that EVERYONE should read in the industry regardless of their role or methodology:

1) Code Complete – McConnell

2) Beautiful Code – Oram & Wilson

3) Godel, Escher, Bach – Hofstadter

The Godel, Escher, Bach addition might surprise some people, but it was a book that profoundly influenced me and the way I think about problems, models, and solutions. Highly recommended.

My #Agile #Pretotype experience

Two months ago I was introduced to the concept of Pretotyping. If I remember correctly, the introduction was through an excellent InfoQ article. The concept and practice intrigued me and I was able to apply it to a project I was working on recently. This is a recap of that experience in the hopes that is may assist others.

Definition

There is an excellent website that provides some great information on Pretotyping. The site is www.pretotyping.org. The definition of a Pretotype that is proposed on the site is:

Pretotyping[pree-tuh-tahy-ping], verb: 

Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.
There are some excellent examples of how Pretotypes can be created using non-technical deliverables like paper or blocks of wood. But whatever the deliverable is, the concept is to create a deliverable that can be used early on to collaborate with the client on the Art of the Possible and then to confirm the high-level scope and functionality without needing to get drawn into the details.
There is a a quote on the Pretotyping site which I feel adds additional clarity to the concept of Pretotyping.
“We did not invent or discover pretotyping; it’s something that a small number of innovators do naturally. As a matter of fact, our concept and formulation of pretotyping was formed by reading and hearing stories about such innovators and the evolution of their ideas. But what these innovators were doing naturally was not exactly prototyping; it did not have a name and we thought it deserved one. We initially coined the term pretendotype because the most unique aspect of this approach was to pretend or imagine the intended functionality. However, since pretendotype was a quite a mouthful, we simplified it pretotype. The concept of pretotyping is also very close in spirit and practice to Eric Ries’ brilliant Lean Startup Movement and the practice of building the Minimum Viable Product (MVP.)”
In Many ways Pretotyping shares much in common with the Agile Practices of Paper Prototyping and UI Design studio. In fact I would argue that a Paper Prototype or the output from a UI Design studio session is a Pretotype. What I find interesting is the possibility of being able to create a Pretotype technical deliverable (more on what these can be later) that can give the client more of a sense of the solution.
And to be brutally honest, I don’t think some clients would be as accepting of a Paper Prototype as a deliverable. Although we know that the value is inherent in both, some people may see the Paper Prototype as being less professional. The ability to create technical Pretotypes allows for the value to be realized while also addressing any client concerns.

My Pretotype experience

So now that we can see the connection between Agile, Lean and Lean Start-ups, and Pretotyping, what was my experience with Pretotyping?

1. A Pretotype is an incredibly valuable tool to be able to design and perform analysis on the large rocks of value for a project and solution without having to get drawn into details. It was a great tool to stay grounded in what value the client would realize as opposed to the colour schemes, particular fields, and other minutiae.

2. It is difficult to communicate to the client and gain agreement as to where exactly a Pretotype will stop and where Prototypes and other deliverables will continue. Although we tried to state as clearly as possible the boundaries, people are used to Prototypes and find comfort in the detail that exists in Prototypes. My only suggestion would be to continue to over-communicate and continue to discuss the differences between a Pretotype and Prototype. My other thought would be to use the actual term Pretendo-type to more overtly communicate the purpose of the Pretotype. (Some people may assume a Pretotype is a Pre-Prototype, while it is a totally different animal)

3. Although the Pretotyping proponents talk about the ability to use paper and other deliverables for the Pretotype, our clients required a technical experience to allow them to interact with the Pretotype in a manner that is similar to the potential end state. The good news is that there are plenty of great tools out there to create Wireframes that can be used to create Pretotypes. Be careful though, the use of these tools can increase client expectations as to how far the Pretotype may go towards being a Prototype.

I ended up using Iplotz as my Pretotyping tool and I was very impressed with the tool. It was very easy to use and also allowed for the all the functionality I required. Iplotz has both an online and disconnected mode. Iplotz also allowed me to group all my Wireframes into a project and let people collaborate of the project. The suite of controls was also very extensive. I have heard great things about Balsamiq as well. There are a multitude of other solutions as well. I encourage you to review the options and decide for yourself which fits your needs the best.

Summary

Pretotyping has definitely found a permanent place in my Agile toolkit. It won’t fit for every project and client, but I believe it will be something that I will use more often than not.

#Agile Pattern Management

I thing I have noticed with individuals that I believe are great team members is that they manage or lead based on sets of data and not just points of information. It has been noted that humans are exceptional in pattern recognition and spatial analysis of those patterns. One news item that got me re-considering this train of thought was the news item where gamers had helped to quickly solve a Protein folding problem with the HIV virus.

In thinking about how humans can recognize and manage by patterns, I think that Agile uses this pattern recognition strength to help ensure that agile projects can be successful. How does Agile do this? I believe there are three ways:

  1. Agile helps to create patterns for review
  2. Agile formalizes the review of these patterns
  3. Agile minimizes the use of non-pattern deliverables

1. Agile helps to create patterns for review

One thing that is implicit in the Agile processes but is not talked about overtly is that all of the Agile processes help to create patterns. Delivering in iterations, User Story Mapping, Kan Ban Boards, Story Slicing, and other practices all create visual patterns that people can review and consume easily. Many of these processes feed into the principles of Visual Project Management with Burn-Up and Burn-Down charts to help communicate project status easily with client Stake Holders. Almost all non-construction tasks on Agile projects result in the creation of Visual patterns that can be used for management and decision-making.

2. Agile formalizes the creation and review of these patterns

Agile also understands that the creation of these patterns needs to be done repetitively and according to a schedule. Like any good experiment, statistics need to be gathered in a structured way so that the numbers of factors changing at one time is minimized. Also understood is that significance of an aberration in a pattern is not after one point but after a succession of points in a larger series of data. To do this we must have multiple iterations of the same size to ensure that comparisons can be made between iterations.

Agile also understands that the creation of these patterns is just one half of the work. By scheduling retrospectives and planning meetings at consistently recurring times for every iteration, Agile ensures that the patterns will be reviewed and actions will be recommended and undertaken if required.

Agile minimizes the use of non-pattern deliverables

Just as important as the creation of these patterns are the minimization of non-pattern deliverables. Agile understands that these deliverables provide inefficient communication of information and their use should be minimized. Any large written document without patterns should be minimized and attempted to be translated into a pattern. These documents are typically the large up-front documents that defined requirements or architecture previously.

Typically you will find that any documentation that can generated patterns are encouraged in Agile. (Such as User Stories and Automated Test Cases)

What is a pattern?

To me a pattern follows these two simple rules:

  1. It can be displayed at a reasonable and readable size on an A3 sheet of paper or on a wall where all the stickies can be easily read and seen within an individual’s  field of vision
  2. It is either a table, graph, diagram, collection of stickies, or a picture

The Agile Pattern Mind set

The last piece of the puzzle is the Agile Pattern Mind set that is required to use these patterns that are created. As mentioned earlier, the great team members on the Agile projects know that some actuals to estimates will be higher and some lower. The experienced team members know when something is not just a data point, but when it is a trend and an issue and requires some action to be undertaken. These team members also know that you can’t over-react on every individual issue and overage or else you will drive your team crazy.

I believe this skill of managing by trends in Project Managers applies equally to both Traditional and Agile Project Managers. The Agile methodology just has a process that creates the patterns that perhaps allows these decisions to be made easier and at the correct time.

#SDEC11 #Microsoft all day session announced! #HTML5 #Mango

SDEC11 has some exciting news. We are happy to announce that we have  added a Microsoft all day session on day 2. This session will be a hands on workshop/dojo on HTML5, Mango, and Mobile Development Hackathon.

The contents of the session are:

An Introduction to HTML5 Awesomeness

In this session, you’ll learn how to take advantage of HTML5 today and into the future! You’ll also see what’s possible with HTML5, enabling rich user experiences across platforms without the need for plugins. You’ll also discover the tools that are available to help you build HTML5 web applications and sites. Come join us for an action-packed session of HTML5 awesomeness!

A Lap Around Mango

In this session, we will provide an overview of some of the hot, new features found in the Windows Phone Mango release and how you can use them in your Mango apps. Features such as taking advantage of multitasking and background agents, live tiles, augmented reality with the camera, use of the gyroscope API, socket support, local database support and many others will be discussed. By the end of this session, you will have the base knowledge of the Mango development process and how to leverage its features within your apps. After this session is done, you will be able to will be able to use the time to code your own apps using while the presenter remains present to answer questions.

Windows Phone and Internet Explorer Hackathon

The afternoon of the workshop will focus on hands-on coding and development of phone and web applications for Windows Phone and Internet Explorer. Apply what you’ve learned through the morning content, and the other great sessions at SDEC, while taking advantage of in-person technical support from technology experts!

This session is included in the conference registration!

To give people time to review this content and sign up we have extended the early bird for the conference until September 15th!

#Apple, #Agile, and being brave

Like all people I was surprised and not surprised when Steve Jobs announced his resignation from Apple this week. With his health issues in the past, it was expected that this day would eventually come. It made me think about my Apple experience and why I respect Steve Jobs immensely.

My Apple Experience

My Apple experience is probably quite similar to many people out there. Early on I resisted working on Apple Technology as I viewed the technology as being limiting and beneath me. I even bugged my brother about his Apple fervor endlessly.  I mean isn’t Apple just for all the people who don’t know technology? I certainly don’t need use one. Then one weekend after I was getting annoyed with the aesthetics and performance of my Windows tower at home, I wandered into Best Buy. I saw the Imac and thought I would give it a try to see how limiting it actually was.

My plan was that I would just use it for browsing, email, and pictures. I had prepared myself for how limiting it would be and how little I would be able to do and have control over. I had told myself that my kids and wife would use it more. And that was true, at the start. Then I found iTunes, the Unix-based OS, iLife, iPods, and how easy everything was. (including uninstalling applications) There really is something to be said about a computer that doesn’t need an instruction manual. I was hooked. The iMac was simple but yet robust.

Now I still use my Windows 7 machine at work and there are things that both technologies excel at.

But the most telling statement is that if I am doing something that can be done on both, I rarely turn on my Windows 7 machine.

What Steve Jobs means to me

Steve Jobs to me is someone who has three competencies not usually found in one person:

  1. Singular Design – I think everyone would agree that Steve has a real skill for looking at designs and products from an end-user perspective. He always sought simplicity with singularity. Singularity is the one aspect I love about Apple products. There is only one way to do something. I find that it sometimes confused the matter when other technologies provides multiple ways. They think they are helping, but all they end of doing is killing Unicorns. It may take a little longer to learn the one way, but it will be simpler after that one way is learned.
  2. Bravery – I think the best quality that Steve Jobs has is bravery. He frequently promoted ideas that weren’t just addressing problems. They typically addressed an opportunity to provide more to the client. They typically were revolutionary and not evolutionary. He then had the convictions to follow through on these  ideas and ensure they happened. I think we can all be a bit more brave and do things that are constantly improving things.
  3. Charm – Steve is compelling, passionate, and inspires confidence. To quote Kramer from Seinfeld: “It is all about poise! Poise counts” I think this poise was critical to execute those brave, singular designs.

I think about being brave at lot in regards to Agile. I always ask myself am I being Brave and creating new ideas and expanding the understanding and use of Agile  or am I just promoting other’s best practices. I think there is a time and place for both, but we are professionals need to ensure we do both.

 

Is #agile #sub-optimal?

I had a comment that was posted in relation to my Solution Driven Development post that took me on a journey of reading on Sunday. It was a comment submitted by Gebhard Greiter.

To be honest, the comment and its references proposed a more rigourous and prescriptive process that what I prefer to see in my Agile projects. (I’m just not sure I’d recommend that the designer is a separate person than the coder) But I appreciated it’s sentiment. Gebhard, like myself, is struggling to find that correct balance between traditional and Agile processes. I commend him for the principle and strength of convictions, even though my preferences in project execution are slightly different than his.

His proposed balance between the two sides of the methodology can be found here:

Comparing two process models for Software Development

There were also some interesting links or sources of information in the comment. The first one was the Principles of Agility 2011. This link then referenced a Gartner report and quote on the potential downside of Agile. I found the entire article that generated the quote and you can read it at the following link:

Agile Development costs more in the long-term

Is Agile Sub-Optimal?

After I read he article, I had two thoughts. One, that the article drew some broad generalizations and perhaps drew some conclusions I would not have drawn. Two, is the author may be onto a small nugget that has been bugging me for a while.

I’ve always been bothered by the lack of ‘project memory’ if I following Agile by the book. If I use User Stories on stickies, Manage via a Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

  1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
  2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
  3. Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can’t anticipate because we don’t have an automated test to ensure its correctness currently.
  4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
  5. How can I easily have new team members support the system? Do they read the code and the tests?
  6. etc….

Active Architecture

I had written a blog post that described my approach to creating Active Architecture Stories as a means to create just enough design documentation so be able to answer half of the questions above. I think the other half can be solved by using one of the leading Agile Project Management tools out there like TargetProcess, Rally, or VersionOne. Any of these tools will allow you to start to build up that ‘project memory’ that can then be leveraged by other projects.

Summary

But the question remains, “Are we sacrificing long-term Enterprise objectives by developing project in an Agile way?” I don’t believe that anyone that argue that Agile is not the best way to execute a project. But I do think that sometimes Agile’s sole focus on value for the project and client may cause us to lose focus on the value the IT Department and the Enterprise requires across all the projects. By its very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance roles breaking down the barriers between projects.

Sometimes we may need to create documentation that the client does not see value in currently. As professionals we know that there are some documents that will be required in the years following go-live that will pay for themselves 10 fold.

Am I proposing functional specifications? Absolutely not. But I think there is a place for more documentation and some up front design and architecture than is usually suggested. The real question is what documents are required that will ensure I can take advantage of all my re-use opportunities and also be able to efficiently manage the application for the next 15 years.

Perhaps we should also ask those questions when we are determining if we need to create documentation.

#agile2011 Monday night thought – Does using only #Velocity limit the opportunities for #acceleration?

I just finished reading an excellent Blog entry on transitioning from traditional estimating to Story Point estimating by Ilan Goldstein. You can find the blog post at the following link:

transitioning-from-timebased-to-relative-estimation

The article walks through the estimation process used during the transition there are three excellent points.

1. I loved the idea about being above-board and listing the conversion table between Story Points and the range of hours typically associated with those Story Points. Let’s face it, everyone is doing the mental math and the only thing worse than people doing the calculation, is everyone using a different version of the table in their own head to do the calculation. So let’s all just agree what that conversion table is. Excellent.

2. Taking previous features developed and incorporating the effort they took into the estimation process is wonderful. I have not heard mention often enough about tracking and comparing estimates versus actuals on User Stories so that our estimating get better each Iteration. This process of creating reference User Stories in points by converting the hours they actually took helps to leverage the previous project work to make the estimating of future work as accurate as possible. Brilliant. The additional step to then throw away the hours per feature and use on the Story Points going forward is ideal.

3. The point to then track both the time completed and the time remaining on active User Stories ensures that we are continuing to learn and get better with our estimating as the project proceeds.

I think these three points just add the value of planning poker and makes the entire estimation process the best it can possibly be.

Why do I like these ideas and processes so much and what does that have to do with the title of this Blog?

It has always been a personal belief of mine that setting completion expectations for a project team with only a collective measure (velocity) for the entire iteration is not optimal. Using relative estimating to produce accurate estimates and using velocity to plan for the average progress of a project is fine, but even Mike Cohn stated he does not recommend using Story Points for Sprint Planning.

why-i-dont-use-story-points-for-sprint-planning

Mike Cohn mentions that velocity is not a useful short-term predictor and I agree. I would also add that not only is it not a useful short-term predictor, but also can possibly not set the proper short-term expectations for User Story completion times. When used, Story Points by their nature allow for a separation from day-to-day complexities that can cause inaccurate estimates. When used, Story Points by their nature can also allow for a separation from day-to-day expectations. For example:

  • How long should a 1,3,5, or 8 point story take?
  • Do we need to wait until the end of an iteration to react to a story that is taking longer than thought?
  • Would knowing that a story should take 2 days on average help to alert the developer of potential issues?
  • Would knowing that a story is going to take longer than expected allow for the splitting of a story in the middle of an iteration and the ability to deliver more ‘Done’ work in the iteration?

If I am for the most part only reviewing velocity at the end of the iteration and not at some level on each User Story during the iteration, am I limiting my opportunities for acceleration?  (Acceleration being the rate I can change my velocity.)

Thoughts?

#Innovation Debt and the Four Fences of Software Development

I was looking for a new picture for the Blog and I thought about an interesting Blog post. As you can see now, I chose the image of a gate after much searching on various image search engines. (let me tell you there are some very interesting people out there with cameras.) 🙂

Gates and Fences

I chose a gate as I think it is a very interesting analogy that can be used in the Software Development industry. In the Agile community we are so focused on tearing down fences that we have to be careful we don’t use the remnants of the Waterfall Fence to build the Agile Methodology fence. I loved the analogy of a gate in conjunction with the fences. We need to ensure that every fence we build also has at least one gate. The fences exist for the purpose of providing structure and restrictions for predictability, but there always needs to at least one way to break free when the situation calls for it.  (hopefully multiple gates)

I thought of 4 separate fences that are quite common in the Software Development industry. They are:

1. Process Fence : Gate leads to greater value

I’ve alluded to this fence already. As I have mentioned, we in the Agile space need to be extremely careful that we don’t construct an Agile fence out of the broken boards of the Waterfall fence. If we start being equally as stringent and demanding, we are equally doomed to failure. Don’t get me wrong, I think the Agile practices are a great fit for the vast majority of projects and an improved over the Waterfall methodology. But we need to be careful that we don’t start to be overly prescriptive and cookie-cutter. It would be incorrect to say all Software Development projects require pair-programming, two-week iterations, and daily stand ups. Just like it was incorrect to say all Software Development Projects required Functional Specifications, Work Breakdown Structures, and Use Cases. Do these Agile practices fit better than Waterfall practices? Usually. But the team still needs to determine what practices best apply and to what extent.

Sometimes you have to open the gate and incorporate all the different practices that deliver the most value to your client. It is likely that these practices will be from many different methodologies. Can an Agile project benefit from a Work Breakdown Structure? It is possible.

2. Technology/Vendor Fence : Gate leads to better solutions

A second fence we can find ourselves in is this Technology or Vendor fence. This is the fence that we typically build around the technology we use and the vendor for that technology. We typically built these fences for very good reasons. Simply put we are more familiar with the technology we use the most and we there just isn’t enough time to learn all of the technologies that are out there. There are just simply too many. So what can we do?

I think similar to the Agile principle about trying one new thing every iteration, Software Development technical professionals should try one new technology every project. (preferably from different vendors) If the project doesn’t allow for this, then we should as Software Development professionals commit to reading one new book and playing with one new technology in our own time for every new project.

If we don’t do this continuous learning and strive to open the gate in the technology fence, how do we know we are providing the client the best solution? Of course we can’t know all technologies, but isn’t it our professional responsibility to know more than one group of them?

3. People/Employer : Gate leads to enhanced knowledge and competencies

The third fence is the people or employer fence. This fence is very similar to the last fence except that it deals with people instead of technology. It is very natural to again build a natural affinity to the people we primarily work with. But it is also important to realize that one company can’t be perfect in everything. (just like one person can’t be the best at everything) We all have our strengths and weaknesses both individually and corporate-wide.

Some of the most valuable lessons learned I have had over the years has been when I have worked with people from other companies and they have shared with me their practices and methods. Now those of us who have worked for a company for a longer duration obviously believe our company has more strengths than weaknesses. (I know this is something I believe 100% about Protegra.)

That said, I look forward to being able to work with new Protegrans and with new partners and clients because I know I am going to learn new things and be the better for it. Opening the gate in the People and Employee fence is one of the most rewarding.

4. Experience/Safety : Gate leads to innovation

The fourth fence is one we build ourselves and it is something I’ve noticed more in myself as I’ve gained experience. I think sometimes when we have gathered more experience, it is easier to just do what we have done before. Developing using a known process, technology or team is the safe route and something we feel more comfortable with. The decision between introducing new items and doing what has been done before is a fine line as we can’t take on too many new things and risk the project, but if we don’t take on any new items we are building what I like to term Innovation Debt.

Like Technical Debt, it is sitting there and charging interest. Innovation Debt will also needs to be paid sooner or later and it is better to pay it off bit by bit on projects rather that having a large payment at the end. The real problem is that too much Innovation Debt can result in a compromised company that is passed by their competitors. Too much innovation on projects can result in compromised projects. It is a very fine line to walk.

But not opening the Experience gate is actually more damaging that opening it. It is just a little unnerving at first and requires an atmosphere at work that encourages innovation and rewards fast failure.

Summary

Those are the four fences and gates that I try to keep in mind as I go about my projects. Does anyone know of any more?

Seek to Understand, Strive to Educate, Commit to objectivity

This post has been percolating for some time in the political and journalistic realms. Very recently it has also found a home in Software Development. But let us start at the beginning.

I love the opinion and editorial section of any paper. I love reading people’s opinions about items in the news. I also find the editorial section extremely enlightening in regards to current events. That is until the last few years. It seems over the last few years, it has been very hard to find a balanced opinion article in the paper. The articles are bordering almost on propaganda. And it isn’t just either the left-wing or right-wing articles. The unbalanced articles are across the board. It seems all the articles are no longer trying to educate or inform, merely convince.

As a Canadian, I am interested in politics in a moderate way. I don’t align myself to any one party and feel that there are parts of every party that I agree with. I am constantly disappointed with political articles, editorials, and opinions that don’t provide a balanced viewpoint. Usually the point of the article is to convince the reader through fear, uncertainty, doubt, and junk science. By reading the articles around the recent Canadian election I would have thought that the leaders of the major political parties were inherently evil, naive, or simple. Of course, none of this is true.

“Education is providing balanced information on the entire issue, propaganda is providing information on only one side of an issue.”

I believe that if a person is 100% aligned with a concept, group, or ideology, he or she has probably stopped being objective.

So what does this has to do with Software Development?

First off, I’d like to provide full disclosure. I am neither a devoted fan to either Microsoft or Apple. My technical assets are:

  • Imac and Mac mini at home
  • Dell laptop at work
  • Blackberry Phone
  • Ipod music device (Classic black if you must know)
  • Nintendo Wii Game System

It seems that Software Development has recently fallen victim to the same hyperbole that has befallen politics and journalism. Many tweets I hear and articles I read seems to imply too quickly and frequently that the specific technology is a ‘game-changer’. Those types of technology happen very infrequently. I shudder every time there is a Microsoft, Apple, or other large technology announcement is made. I know there is going to be a plethora of tweets stating how Windows 8, OSX Lion, or Google+ is going to rule the world and be a game-changer. Even methodology discussions are victim to this behaviour with the demonizing of Waterfall and the praising of all things Agile. (without acknowledgement that there are situations that each excel at)

But more it seems that people are becoming 100% aligned with products and vendors. Can they really be considered objective? Shouldn’t there be some products from preferred vendors that they don’t like? Am I the only one that thinks Google+ is mainly Facebook+Skype+new cool user interface for groups? 🙂

Truth is that I would love to read more balanced articles that seek to understand these technologies, strive to educate me on these technology options (good and bad), and then commit to provide a balanced objective critique.

I know I myself have provided these somewhat one side articles in the past, but  am going to try to focus on providing more balanced articles going forward. You may not agree with my conclusions, but at least I will try to paint the picture in a balanced way that lets you decide for yourselves. Sometimes I may like Microsoft, sometime Open source, sometime Apple, sometimes COBOL….