Erik on Software

Certified ScrumMaster Training: Day 2

Notes taken for posterity during the second of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• Release planning was pulled out of the July 2011 Scrum Guide, which returns Scrum to its original definition, but the Scrum Alliance will continue to include.
• Definite delivery dates, cost, and scope are not included in Scrum release planning. Release planning is not the purpose of Scrum. The purpose of Scrum is to be transparent and to determine what is available when.
• Scrum and Extreme Programming (XP) arose from the Patterns movement, because each of these is based on natural practices. Patterns are discovered, not invented.
• A release plan really just indicates which Sprints involve a shipment.
• Estimating is really design, because the clock is not brought into the equation. The conversation becomes more comfortable because the subject matter is more familiar and the entire development team is involved.
• Sometimes "ideal days" are used instead of story points, but for some this brings time back into the equation, which is not the objective. According to the instructor, ideal days in general tends to work.
• Larger tasks tend to be underestimated. The instructor advised not assigning numbers when an estimate is too much of an unknown, because estimates will be thrown off. This forces stakeholders to be aware that these larger tasks need to be broken down in the future. It is the stakeholder's call whether to spend time on one or more Sprints assigning estimates to these larger tasks.
• If there are many small tasks, it is permissible to bundle them as long as it makes sense to do so. In other words, the tasks are related and can be completed within a Sprint.
• Planning Poker sets are typically based on Fibonacci, so the instructor tends to suggest this sequence.

---

During the discussion, I had mentioned Powers of 2 as being popular, but the instructor tends to think that the numbers in this sequence increase too quickly. In speaking with some colleagues, we agreed that Fibonacci and Powers of 2 are similar if capped at say 16, and I later distributed a presentation I delivered a couple years ago that included several slides on how Powers of 2 were used for story points and how spikes were used on my project to assign story points to the building of proof of concepts with unfamiliar technologies that were planned to be used on the project. But since it is not always reasonable to cap at a certain number in the sequence, in retrospect I will be considering other sequences such as Fibonacci in the future, especially since we enjoyed using a traditional card deck to play Planning Poker (Ace = 1, 2, 3, 5, 8, Jack = 13, Queen = 21, King = 34).

During an exercise where the class broke down into 2 teams, we used Fibonacci to estimate tasks associated with kitchen remodeling.

The points that my team assigned to each of the tasks are listed on the left. Points are relative, and we did not see any tasks as being far removed from the others in terms of points. However, we did not end up assigning any points to the last task listed, because of the disagreement that ensued regarding the work to be completed. This task is an example of where a portion of a Sprint might be assigned to additional estimating.

The other team viewed the first two tasks as being relatively far removed from the others in terms of points, and in this case it is understandable how Powers of 2 might not be appropriate. As discussed by the teams following this exercise, the points assigned are either a reflection of unfamiliarity of this type of work, or the relative difference in skills between the individuals on each of the 2 teams.

---

• This type of estimation is really qualitative, not quantitative. Affinity Estimation enables quantitative estimation and is the fastest way to estimate a product backlog. The rule is that if a story estimate changes 3 times, it is set aside. Not only is time removed, size is removed. Affinity estimation is relative. The Fibonacci series is then applied afterward. The team quickly develops collective intuition.
• XP introduced the "courage value", which takes the lower number, rather than a conservative higher number, in the case that a team does not reach a concensus.
• During a class exercise that involved measuring velocity, the instructor pointed out that the team that is participating needs to be involved in estimating. Those not involved are not qualified to interpret past velocity activity.
• Use of Scrum is always forward looking by evaluating the past. What the instructor refers to as "Point Accounting" comes into play as tasks are not completed and work needs to be forwarded to the next Sprint. One strategy is to figure out how to complete a subset of the task in the first Sprint, and then forward the remainder. Another strategy is to move the entire task to the next Sprint and then count the points for the whole task. The instructor does not necessarily like this latter method, but for a services company like ours it might make sense.
• The Sprint is the only timeboxed item that cannot be changed.
• Part 2 of Sprint planning is where the bulk of planning occurs. The first part of planning tends to go quickly because much of the work is performed in the prior Sprint.
• Velocity should be used to determine what the development team thinks it can complete in a Sprint, not what it needs to complete in a Sprint based on expectations.
• It is rare that developers will sign up for risky tasks.
• Be careful about assessing importance based on the task name in itself, because for example the task might be associated with strategic work that is trying to set the stage for future Sprints.
• The Burndown Chart tracks how many hours remain, not how many hours have been applied to tasks. Keeping track of how many hours have been worked can be separately maintained elsewhere.
• The "truck number" is sometimes used to communicate how many people need to be run over for a particular skillset to be lost. A truck number of 1 is obviously never desired.
• It is a good idea to reserve a portion of points in each Sprint for support activities.
• It also sometimes makes sense for the experts on the team to be assigned no points in order to raise the skillsets for the rest of the team.
• Kanban is really an evolution of Scrum where work needs to fit into more traditional phases.
• It is not the purpose of the daily Scrum to report to the ScrumMaster. The purpose of the daily Scrum is for individual developers to share status with the rest of the team.

---

Interestingly enough, the role of the ScrumMaster in the daily Scrum was one of the topics that lingered during hallway chats while back at our client the next day. In our experience, it is common that ScrumMasters will address the rest of the development team one at a time during the daily Scrum, reminiscent of status reports to a project manager, but this should be taken care of prior to the meeting itself so that developers can share with each other. In my opinion, reverting back to the traditional status report format with which many are familiar is common when trying to create a Scrum hybrid that blends Scrum with current state client project methodologies, but should be relatively easy to steer away from when there is common understanding across the development team as to the purpose of the daily Scrum.

---

• The Burndown Chart should not be updated during the daily Scrum. The team should update before the meeting so that it does not lose its purpose.
• There should be a common vision coming out of Sprint planning that the team has a shared commitment. The purpose of the daily Scrum is not to focus on your own work as an individual.

---

Another topic that was discussed periodically the next day was the Ball Point Game exercise in which all attendees participated as one big team. For this exercise, we were to pass tennis balls to each other in a way where everyone touched each ball before it was placed in the bucket. But there were stipulations which stated that air time was required between each person, that balls could not be passed to direct neighbors, and that the person that passed the ball first also must be the person that touches the ball last.

And it so happened that I was the individual that was the one that passed the ball first and touched the ball last. By the nature of this position, I was also the one that kept count of how many times balls entered the bucket. Very challenging. Everyone remarked the next day how I was the one with the hardest task. Much like the ScrumMaster. Two of the many take-aways were that we found rhythm as at team after the first few Sprints, and that time spent on Agile Retrospectives is very small compared to the rest of each Sprint.

The exercise ran for 10 Sprints. During the first 3 Sprints, our velocity increased. Following the first 3 Sprints, I suggested we create a new formation and so velocity decreased while we were finding our rhythm again. Other suggestions on formation ensued, and velocity rose again until we found a more optimal formation in which velocity continued to accelerate. It is probable that had we run the exercise for additional Sprints we would have continued to increase velocity prior to reaching our limit.

Certified ScrumMaster Training: Day 1

Notes taken for posterity during the first of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• The course started by individual attendees identifying 5 of 22 provided topics that we thought might be important take-aways, followed by the class breaking up into pairs in order that one might convince the other to switch one of the 5 chosen to another topic.
• The 5 topics I had chosen were items I had not yet encountered to any significant degree in the workplace or graduate school, such as specific artifacts and distributed Scrum. The plan was then to apply post-it notes to each of the 5 topics as they were covered in class.

---

Of the 22 take-away concentrations, the following 5 were the most popular in this class session (all written intentionally in the form of user stories):

7- I can describe how to use the Scrum framework on large projects using Scrum of Scrums and/or other approaches to scaling.
6- I can facilitate the team through the Sprint.
6 - I can advocate for Scrum teams to be colocated, but also help a team overcome the reality of distributed teams.
5 - I can explain the importance of complexity and its impact using empirical or defined processes.
5 - I can describe the responsibility of the ScrumMaster.

These types of exercises tend to interest me, because much of the value add for me in corporate training tends to come from the interactions between colleagues rather than the material itself.

---

• The latest Scrum Guide released 3 weeks ago was included in the handout workbook. The instructor noted that the release planning portion was removed from the previous Scrum Guide.
• Development of the Certified Scrum Professional from the Scrum Alliance had its origins in the failure of the Agile Software Development with Scrum text by Ken Schwaber and Mike Beedle and the desire to help realize Scrum practices in its readership.
• According to the instructor, worldwide there are about 160k Certified ScrumMasters, about 10k Certified Scrum Professionals, 130 Certified Scrum Trainers, and an unknown number of Certified Scrum Coaches and Certified Scrum Developers.
• The instructor also noted that there is some redundancy between Certified Product Owners and Certified ScrumMasters. Although Certified ScrumMaster Professional is the drive right now, it is not a certification that should be called out in one's email signature etc because it does not represent skills or experience, just understanding.
• In Scrum, "programmer" is not equivalent to "developer". The development team is comprised of the programmers, architects, business analysts, testers etc with which we are familiar, and all are developers. In addition, the Scrum team is comprised of both the product owner and the development team.
• Deliverables are intended to be in a shippable state at the end of each sprint, but not necessarily shipped or deployed to production. To release to production is a business decision.
• Identified tasks are not an explicit requirement of Scrum. The development team determines how this is to be done. Even though tasks are the most common method to plan, this requirement was removed in recent releases of the Scrum Guide.
• Project resource needs are starting to be requested in terms of Scrum teams of x people for x months.
• During our discussion of Scrum motivations, we discussed at what point project tasks are performed during traditional Waterfall and Scrum project timelines. It was amusing for the my colleague and I to find ourselves working through estimation, requirements, analysis, and design, and then working backward from production deployment to fill in the rest of the activities for traditional Waterfall.

---

During class, I recalled to my colleagues the practices that one of my project managers followed early in my career following the implementation of an enterprise-wide project dashboard. The project manager would spend considerable time each week tweaking the project plan until it would turn green, and consistently trimmed estimates provided by my colleagues in order that they would fit in the predefined timeline, not unlike the Waterfall portion of this exercise.

---

• Scrum is similar to Extreme Programming (XP), except XP has more constraints around how programmers are to perform tasks.
• Project complexity is really the driver to determine whether to take an empirical approach. Requirements and technology (and maybe organizational complexity) determine complexity, not factors such as team size and colocation of team members etc.
• Of the 3 pillars that uphold every implementation of empirical process control (transparency, inspection, and adaption), adaption is usually the most difficult. The question ends up being: What is the most tolerable empirical approach for my organization today? And agile hybrid approaches are common.

---

After discussing project complexity and empiricism, we broke up into teams of 3 and 4 to discuss the 12 principles behind the Agile Manifesto, and chose 3 principles that we thought can be removed, and 3 principles that we thought are the most important.

Across the teams in this class session, the following 3 were the most popular for principles we thought are the most important:

3 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2 - Working software is the primary measure of progress.
2 - Business people and developers must work together daily throughout the project.

The following principle was the only one that managed to get any hits for being removed from the Agile Manifesto:

2 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The instructor indicated that some of the writers of the Agile Manifesto have indicated that some of these principles would have been better left out, but that coming to agreement on these principles during a relatively short meeting 10 years ago was a huge achievement. That said, this exercise resulted in considerable debate.

One principle that generated debate was as follows: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." One team argued that "requirements" is often assumed to be business requirements, but the term can also be assigned to technical requirements, and so they argued in favor of this principle.

Another principle that the teams did not generally agree upon was as follows: "Business people and developers must work together daily throughout the project." The term "daily" was the catalyst of the disagreement, because of the mandated frequency of working together.

My team chose the following principle as being one of the 3 we thought are the most important: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly." Speaking from my experience, I have witnessed the value that the Agile Retrospective provides, having used them on multiple projects throughout my consulting career.

---

• One problem that the instructor has witnessed is that few Certified Scrum Trainers have been product owners. Most have been programmers and project managers.
• According to Scrum, only one person is intended to be product owner, but in practice this is very difficult.
• There appears to be a move in the Scrum community to replace "prioritizing" with "ordering" the Sprint Backlog, and "committment" language has been replaced with "forecast" in Scrum literature, although the instructor prefers the original verbiage.

---

Unfortunately, I introduced the term "semantics" as part of the discussion on prioritizing versus ordering. What I had intended to convey was that "prioritizing" seems to communicate business needs or wants, whereas "ordering" seems to communicate the order in which tasks need to be completed, perhaps because of dependencies between tasks.

---

• A lot of discussion surrounded the term "shippable" during the portion of our class session working on an exercise where we broke out into teams of 3 and 4 to talk about our current projects and what we can do in each Sprint, what we would like to do in each Sprint but are not able to do today, and what tasks should not be considered as needing to be completed in a Sprint.

---

The term "shippable" is intended to convey that a deliverable is in shippable state. In other words, it can be released to production or shipped to customers, but is not for any of a number of reasons. For my contribution to this exercise, I indicated that during my upcoming project, I might consider refactoring a task to be done as part of a Sprint, but tasks such as load testing probably fall outside the Sprint, and that I may like to include testing on counterparts to the proprietary appliances that are expected to be used in production, but will probably not be able to do so. 

---

• In addition, the instructor said jokingly that "what goes on in the Sprint stays in the Sprint", meaning that hand-offs between programmers and QA for example within a Sprint should not be counted as defects. Remaining defects go back in the Sprint Backlog if not resolved during any particular Sprint. In Scrum, a defect is just work prioritized by the product owner.

Mono in Transition; C# or Objective-C?

Funny that although I have been trying to cancel my "InformationWeek" magazine subscription for quite some time, just as the publisher threatened that the June 13, 2011 issue "may be one of your last unless you revew now" comes an article, ".NET Alternative in Transition", that finally peaks my interest, partially because the publisher beat some of my other traditional sources of technology news, but partially also because of the relevance to the cross-platform mobile development project I started earlier this year and discussed in a series of blog entries.

Work on open source project Mono, originally started by Ximian in 1999, continued to flourish after being acquired by Novell in 2003, but Novell was in turn unexpectedly acquired by Attachmate in November, 2010, the sale of which completed in April, 2011 alongside a sale of "certain intellectual property assets" to CPTN Holdings, a consortium led by Microsoft, that included Mono. Attachmate fired the entire team of Mono developers in May, 2011, and although it retains intellectual property rights for Mono, much of which is copyrighted by Novell and available under an open source license, lead Miguel de Icaza moved quickly to form a new company, Xamarin, with the core Mono development team.

De Icaza's first goal is to push ahead with Mono on mobile devices, specifically Apple iOS and Android, with development in Microsoft C# (which he describes as a "beautiful language") on mobile devices as the first priority. True portability between these two platforms and Microsoft Windows Phone is the goal, and Xamarin Studio is set to be released later this year. De Icaza clarifies this direction in an interview with "Application Development Trends" magazine. Because Novell owns some of the technologies that the Mono team has already built, such as MonoTouch and Mono for Android, Xamarin needs to build some of its initial products from scratch, including new .NET incarnations for Apple iOS and Android. De Icaza:

At Novell we built both open source and proprietary products. The open source code is, well, open source. And the proprietary things are owned by Novell. We need to rebuild those things if we want to be in the market with similar products.

In response to de Icaza's original blog entry, it is apparent that there is a lot of discussion surrounding pricing, because Xamarin offerings are planned to be commercial. Of course, the other common discussion point is the viability of these products, which Xamarin currently plans to release as a suite. As one commenter to de Icaza's blog entry mentioned, Android already has Java, and Windows Phone already has C#, so C# for Apple iOS might be seen as one of the only real benefits being offered here (i.e. no need to program in Objective-C, which does not have a reputation for being a "beautiful language"), even given the fact that platform portability is what is being sold.

"Hello Android": Part 3

It did not take too long to come to the conclusion that my short-term satisfaction with the Android development environment I had just built had come to an abrupt halt. The main reason behind this change is the fact that Ubuntu 10.04 LTS does not support dual monitors for the driver currently installed on my old IBM ThinkPad T42. According to Linux (output is edited to include only video driver information):

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Subsystem: IBM Device 0550 Flags: bus master, fast Back2Back, 66MHz, medium devsel, latency 66, IRQ 11 Memory at e0000000 (32-bit, prefetchable) [size=128M] I/O ports at 3000 [size=256] Memory at c0100000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at c0120000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon Kernel modules: radeonfb, radeon

My extensive web searches brought me to realize that the Radeon 9600 is no longer supported by Ubuntu via the manufacturer's driver, so my only choices at this point are to purchase a new laptop, go back to Windows and use an Ubuntu virtual machine, or limit my work to a single monitor. None of these choices sit comfortably with me. Especially frustrating in this regard is the fact that the Ubuntu "monitor preferences" panel seems to indicate that dual monitors are a possibility even though it is not.

Apart from this relatively small sacrifice, progress has been made over the last couple weeks with the limited time I currently have available away from the office. The decision to not pursue the native development route has won for now. There exist just too many cons via that avenue rather than pursuing HTML5, especially since cross-platform adoption is sought in a fairly short period of time.

In the past couple weeks, I have had the chance to test a few JavaScript frameworks, including jQuery Mobile, currently still in infancy, although having its origins from jQuery, a mature framework. My tests ran well, but I am not sure whether it will catch on, meaning that near-term community support is an unknown. Other mobile development frameworks based on traditional JavaScript frameworks are also available, such as dojox.mobile, which is embedded within the Dojo Toolkit.

The level of architectural decision making on this project is more extensive than originally expected, even though native development is not being pursued. Well, not quite. Based on current direction, a portion of the development on this project is likely to require the porting of code from one platform to another for a portion of the back-end, which does not exactly meet the pure cross-platform goal, but possible workarounds are currently being assessed.

Porting is being laid to rest right now in favor of getting some of the core user functionality to work. While I had originally considered the user functionality enabled by the porting to be core, I have come to the realization this is simply not the case, and considerable coding needs to be done apart from this extended functionality (actually "just" a convenience measure for users).

After some success using the PhoneGap framework today, it looks like it will probably make its way into the architecture for the core user functionality portion of the application. Several elements of a steel thread have been constructed across multiple proof of concepts, so one of my next steps will be to unite them together into one application after making some decisions as to which JavaScript frameworks will be adopted.

Since my last post, the following high-level installation step were also performed:

• Installed FireBug to my laptop Firefox install
• Set "security.fileuri.strict-origin-policy" to "false" using Firefox "about:config"
• Installed Android Debug Bridge (ADB) 1.0.26 to Eclipse using Android SDK and AVD Manager:
• Enabled USB debugging on my Droid Pro
• Added "android:debuggable="true" to the <application> element in the AndroidManifest.xml for each application
• Created "/etc/udev/rules.d/51-android.rules" with the following entry:
SUBSYSTEM=="usb", SYSFS{idVendor}=="22b8", MODE="0666"

These steps have enabled me to start debugging my applications locally on my laptop, as well as on my Droid Pro. While applications can be installed to my phone via ADB, and run successfully, the one glitch I am experiencing right now is that after closing an application, I cannot run it again without rebooting the phone. This glitch is probably resolved easily, but my time is limited and solving this issue will need to wait until next time.

 

New Book Review: "Just Enough Software Architecture"

Recently posted book review for Just Enough Software Architecture: A Risk-Driven Approach, by George H. Fairbanks, Marshall & Brainerd, 2010, reposted here:

During my last year of graduate school several years ago, I wrote reviews for two software books that I still consider exemplary: "Object Technology: A Manager's Guide", by David A. Taylor, which I called "the best concise introduction to object-oriented technology", and "Software Architecture in Practice", by Len Bass, Paul Clements, and Rick Kazman, the software architecture Bible at the time. As a consultant whose experience includes software, systems, and enterprise architecture, "Just Enough Software Architecture: A Risk-Driven Approach" is the book I will now be recommending to software developers who either have no architecture-level experience, or who need to get back to the basics of what software architecture is really all about.

Although I recently rated another text entitled "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" with high marks, I commented in my review that "after reading [that] book the reader will likely leave with an understanding of a broad range of architect responsibilities communicated by dozens of different architects with varying levels of experience across numerous business industries", and that "the degree to which their thoughts subtly differ on this aspect somewhat reflects what one will find in the workplace, especially when working as a consultant". However, for a cohesive treatment of software architecture, the goal of which is to start students and professionals on the right track, there are no other texts than can stand up to this one in the year-2010 marketplace.

Thinking back to my use of both the first and second editions of "Software Architecture in Practice" during my first graduate-level architecture course, I remember using the second edition to a greater extent than the first edition because of its use of UML. In fact, I had been known for quite some time to be a bit of a stickler for proper UML notation. Now I am known to combine component and deployment diagrams on a frequent basis just because it often makes sense to do so (if the tools being used are permissive in that sense). That said, the only aspect of the content that Fairbanks provides that I am not sure about is the ample use of legends within UML diagrams to explain what different lines and shapes convey. Because the goal of this book is not to teach UML, however, holistically speaking this is just a slight annoyance.

The first part of this book, "Risk-Driven Software Architecture", is what I especially enjoyed about what Fairbanks has to share with readers. Right off the bat, the delineation that the author provides between the job role of "architect", the process of "architecting", and the "architecture" engineering artifact is well done, as are his explanations of risk-driven architecture and agile architecture, and why software architecture is important. In addition, the extended example of risk-driven software architecture approach usage is effective, especially the points that the author makes about team communication, an extremely important aspect of architecture that is somehow often missed in other works of this genre.

Of the chapters within the second part of this book, "Architecture Modeling", I especially enjoyed Chapter 13, "Model Relationships". Although perhaps best read by novice architects, as a professional I found this chapter appealing because I have noticed the prevalent misunderstanding that exists in industry of how models relate to each other, and Fairbanks writes extremely well in this chapter as with the rest of the book, patiently walking the reader through every step along the way. Some potential purchasers of this book might be interested in knowing that the author shares effective "further reading" sections throughout that not only suggest other books to read, but provide CliffsNotes-styled commentaries of why each should be read. Well recommended.

New Book Review: "Information Systems Transformation"

Recently posted book review for Information Systems Transformation: Architecture-Driven Modernization Case Studies, by William M. Ulrich and Philip Newcomb, Morgan Kaufmann, 2010, reposted here:

Since the marketplace is largely absent of texts discussing the modernization of software systems architecture, this reviewer did not know what to expect from authors William M. Ulrich and Philip H. Newcomb. In addition, the space of this topic can be very large depending on how it is defined. In the opinion of this reviewer, the best part of what the authors present are the ten case studies, which comprise the bulk of the content, but the initial chapters and concluding chapter provide some initial high-level guidance for managers looking to pursue modernization projects for the first time.

While the case studies presented here offer a variety of scenarios, the potential reader should note that there are some commonalities across these scenarios as well. The tooling and processes utilized across these case studies are shared to a large extent, although there is definitely variation depending on the systems and firms involved. Newcomb is CEO of The Software Revolution, Incorporated (TSRI), and so some of the commonality is due to the tooling and services provided by his firm, for example. The variation provided is largely due to type of system, associated technologies, and modernization approach.

During their initial discussion of challenges facing most enterprises today, the authors note that there is "a lack of understanding by executive teams regarding the impact of these issues and the actions that can be taken to address them for the betterment of the business environment" and that "it is of great concern that software and data assets are largely a mystery to management and planning teams". In following up this discussion with salvaging or rehabilitating legacy systems to provide business value, the authors offer "architecture-driven modernization".

Architecture-driven modernization is defined by the authors as "a collective set of tool-enabled disciplines that facilitate the analysis, refactoring and transformation of existing software assets to support a wide variety of business and IT-driven scenarios". Ulrich later discusses "the four corners of modernization", which consist of modernization scenarios, modernization tasks and disciplines, modernization technologies, and modernization standards, and argues that scenarios form the basis for modernization roadmaps.

Common modernization scenarios include IT portfolio management, replacement/rewrite, COTS package deployment, architecture consolidation, Model-Driven Architecture (MDA) migration, SOA transformation, data architecture migration, user interface refactoring, application improvement, language/source artifact transliteration and platform migration, and data conversion. Ulrich argues that management should be creative and look at a mix-and-match approach that addresses their requirements, and as a consultant who has been a participant in several such endeavors, this review wholeheartedly agrees with this assessment.

As an architect, this reviewer especially enjoyed the following case studies: "Modernization of the Eurocat Air Traffic Management System (EATMS)", "PowerBuilder/4GL Generator Modernization Pilot", and "Veterans Health Administration's VistA MUMPS Modernization Pilot". Note that each of the ten case studies was written by a different set of authors, so the subject concentration and writing style differ greatly between each. Diagram and table effectiveness also varies considerably, and it is no accident that apart from the subject matter of the three case studies sited, these case studies also excel in these areas.

The first of these three spends considerable time discussing all of the steps performed during transformation of Ada 83 code into C++ and Java (the Java solution won). concentrating on performance and duplication of the exact functionality provided in the original system. In contrast to low-level detail, the second of these three concentrates at the high-level, providing a high number of relevant architecture diagrams (to which this reviewer is partial). This reviewer enjoyed the third of these case studies from a business domain perspective, since it concentrates on health care system modernization.

While no book can offer detailed advice specific to the challenges a given potential reader might face in this space, in the opinion of this reviewer the authors offer solid introductory advice on how to start tackling a modernization project, and provide a wide enough variety of case studies that readers can get a feel for what they might encounter in pursuit of such a project. The discussions that the authors provide here definitely delve into the technical, but it is perhaps managers that will benefit the most from a reading of this book, especially the sections that discuss assessments and scenarios and issues underlying traditional approaches such as greenfield replacement and use of COTS software.

Countdown to 2014

In his most recent (October 25, 2010) Computerworld magazine opinion piece, Frank Hayes discusses a debt that corporate IT departments need not pay. Perhaps a majority of readers of the magazine are already familiar with "IT debt", because Hayes mentions the term multiple times within his article but never defines it. The concept is all too familiar to those of us working in the technology space, but I personally do not remember hearing the term until just a few years ago, and since that time the frequency of individuals conjuring up the term seems to have increased.

About a year-and-a-half ago, I came across a discussion of "IT debt" or "technical debt" in a book edited by Richard Monson-Haefel entitled "97 Things Every Software Architect Should Know". While I had mixed feelings about the book at the time of reading (my original review is available here), after listing some of my favorite essays I wrote the following about the contribution by Burkhardt Hufnagel:

By far "Pay Down Your Technical Debt" is the most creative of the lot and could be greatly expanded upon in a title such as that in risk management. Here is an exerpt: "So why the concern over making changes properly now versus later? It's because there's a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called 'interest', and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid".

Earlier in his essay, Hufnagel mentions that such technical debt is incurred due to making a "quick and dirty" fix rather than implementing a fix the "right way" after software is already in production, and that "as the project's architect, you'll have to decide which makes more sense and then convince the decision makers to take your advice; and, as with most architectural issues, there is a tradeoff involved". The complete text of this essay is freely available with the rest of the book here, but I have already quoted half the essay, since most of the essays are limited to two pages.

Apparently, this terminology has been around for quite some time. Ward Cunningham, who reportedly developed the first wiki, is quoted as writing the following in an OOPSLA report dating back to 1992:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Last year (2009), Cunningham reflected on his debt metaphor in a short video where he mentions that a lot of professionals misquote him by explaining technical debt as coming back to clean up code after writing the code poorly the first time around. Instead, Cunningham had indicated that technical debt is what is incurred after developing a solution and not properly or fully understanding the problem, and so the code would need to be revisited after greater understanding is achieved.

One can argue over whether Cunningham's original explanation can be expanded upon, but I do think that Hufnagel's limiting the concept of technical debt to released software is too limited. For example, it can easily be argued that debt can be incurred during the first iteration of a four iteration software development cycle even though the associated software has not yet been released to production.

Regardless, however, it appears that Gartner estimates outdated software like Internet Explorer 6 (IE6) has created a "global IT debt" of $500 billion that is expected to rise to $1 trillion by 2015. The closest Hayes gets to a definition of this debt is the "cost to update old apps so they're shiny and new and fully supported". As an architect, I hope that this thinking is severely limited to a small group of CIOs chasing shiny objects.

The point of Hayes' latest opinion piece, however, is to actually argue that it is worth defaulting on some of this technical debt. He goes on to explain:

Look, how did those IE6-dependent users get into that position? They bought into the last big paradigm of software development: the Web browser as platform. Remember? All our apps would be built with a Web front end. Microsoft thought that was a fine idea and built a lot of non-standard features to lock customers in. Vendors and corporate IT shops used those features to make their Web apps just like regular Windows apps - and users were locked in for good.

How will these users get out of this mess? When the time (and budget) is right, they'll jumpon the next big software development paradigm. They'll buy or build fresh, junk the old stuff completely and go about their business.

IT debt? They'll walk away from it. And why not? Those apps built on IE6 may be creaky, ugly and nonstandard, but they still work. And Microsoft may hate its nine-year-old miscalculation, but it has promised to keep supporting IE6 until 2014.

Besides, how much sense would it make to patch up those old clunkers or migrate them to newer browsers? None at all. Those old apps were designed for business needs from as much as a decade ago. Technical upgrades won't solve that. Building or buying new apps will - and doing that will cost the same, whether the apps they're replacing are up to date or ready to collapse.

The sensible thing is to keep running those IE6-dependent Web apps until they can be replaced with new apps that run from the cloud or on tablets or using whatever the hot new paradigm is.

The question in my mind here is whether the debt to which Hayes alludes refers to financial cost only. If so, he might have a point. But reading between the lines, I think the cost goes far beyond the financial to include opportunity cost. Hayes actually indirectly mentions opportunity cost by referring to continued use of old applications that address old business needs. He refers to present development cost, but not the cost of lost opportunity incurred over all the years since the associated software lost its relevance. That is the true technical debt.

(The quote that opens Hayes' essay is a classic: "We have to use IE6," a contractor at one telco told me recently. "We have all these Web applications that won't run on a browser that isn't broken.")

SpringOne 2GX 2010 Day 2: Keynote

After returning to work Thursday and catching up on some sleep following my attendance of the SpringOne 2GX 2010 conference held at The Westin Lombard Yorktown Center in the heart of the Lombard / Oak Brook, Illinois business corridor, the following are some notes taken following dinner during the second keynote address led by Adrian Colyer, SpringSource CTO and leader of open source project AspectJ. (Notes taken during the first keynote address on Day 1 of the conference can be found here, and the complete session schedule for the week (Tuesday evening through Friday afternoon) is located here.)

Along with Colyer, a few other individuals spoke directly to specific products within and around the SpringSource lineup. This second keynote ran much more smoothly than the first, and all of the software demonstrations appeared to have worked, unlike during the first where network connectivlty periodically stalled (or stopped) demonstrations. In contrast to Rod Johnson, rather than working up to a theme Colyer announced the theme of his keynote to be "Happy Hour at the Microbrewery", a theme which is of course meant to be humorous, although giving no indication of keynote content.

Colyer opened up his keynote by displaying an animation that showed the history of Spring Framework 3.0 by graphically depicting Subversion commits over time using Spring Batch, Spring Integration, and WebSocket API (and incidentally, this was the only or one of the only mentions of Subversion the entire evening; all other mentions of version control focused on Git).

This demonstration was then immediately followed up by Colyer with a question: "How can I move applications through the development, testing, and production environments easier?" He then presented "Spring Travel", the Spring MVC and Spring Web Flow reference application powered by Spring on GAE (Google App Engine) that can be found here, followed by essentially the same application hosted on VMforce, which combines the Java programming language, the Spring Framework, and the Force.com cloud platform. This second reference application can be found here.

Spring Framework 3.1 introduces "environments" and "profiles" which are intended to enable movement between environments more efficiently and can be activated via web.xml, systems properties, or environment variables. One or more profiles can be set as default. (In the midst of this discussion, Colyer announced that Spring Framework 3.0.5 was released earlier in the day.) Essentially, what was being sold here is environment-based property injection.

In addition, Spring Framework 3.1 introduces a caching abstraction via the @Cacheable annotation for incorporating pluggable caching strategies into applications. The @Cacheable annotation uses Spring AOP and AspectJ under the covers, and can be invoked using

<cache:annotation-driven ... />

Caching can be provided via the @Cacheable annotation at the local node level, but distributed caching is also available. The following swappable distributed caches are built in: Ehcache, Coherence, GigaSpaces, and GemFire (recently acquired by SpringSource). Colyer offered a simple description of distributed caching: "horizontally scalable data fabric" that enables "data shuffling" between two WANs.

Colyer followed the caching discussion by what he described as an "enterprise integration fabric", horizontally scalable messaging fabric that enables WAN integration via AMQP (a standard that provides messaging interoperability via a wire-level protocol rather than at the API level like JMS). RabbitMQ implements the AMQP standard and was recently acquired by SpringSource, and emphasized that all it takes to install the software using the Brew package manager is

> brew install rabbitmq

Spring Rabbit is an implementation of RabbitMQ and is the first implementation of Spring AMQP. Under the covers, calls by Spring Erlang are made to Erlang from Java (RabbitMQ was developed with Erlang). I am sure you have noticed by now that a number of technologies are being brought under the Spring fold. In addition, some of the technologies mentioned during the first keynote were revisited by Colyer during his discussion, albeit at a more technical level.

Colyer extended the discussion of NoSQL started during the first keynote, by first reviewing some of the products in this space - Apache Cassandra, Redis, MongoDB, Apache CouchDB, Neo4j, GemFire, BigTable, Apache Hadoop, JCR, and Riak - Graeme Rocher, project lead and Grails co-founder, was introduced to present NoSQL with Groovy and Grails (SpringSource acquired G2One, the company behind Groovy and Grails, in 2008).

Rocher opened with an answer to his own question as to how Grails users can work with data stores (GORM), and offered a discussion on GORM for NoSQL. During his demonstration of using GORM for Redis, Rocher focused on its ease of use:

• start up the Redis server
• create a Grails project using SpringSource Tool Suite (STS)
• open plugin manager
• uninstall Hibernate plugin
• install Redis plugin
• create domain class
• load Grails console
• start executing methods

Following the demonstration, Rocher indicated that a lot of the NoSQL products address specific problems like scale, and announced that GORM for GemFire was being made available for immediate release, a demonstration of which followed where he again emphasized ease of use. On the tails of the GORM for Redis demonstration, he executed the following steps:

• install GemFire plugin to STS
• load Grails console
• kill Redis server
• start up GemFire

> grails gemfire-generate

> grails start-cache-server

• start up two Grails consoles
• start executing methods from either console

Rocher indicated that each of the Grails consoles were running in a separate JVM. In addition, he emphasized that support for continuous querying was added for GemFire. After turning this feature on during the demonstration, he showed how results for a continuously executed query were displayed in the other console, which has implications for a wide variety of usage.

Colyer returned by introducing the Spring Data project, a programming model for productivity and consistency across a wide range of NoSQL products, the M1 release of which is planned for 4Q2010. During this introduction, he provided a preview for a CouchDB demonstration to be presented in a conference session later in the week that will show offline data access and synchronization with continuous bi-directional replication between an Android mobile phone and a Spring application server.

Keith Donald, SpringSource principal and founding partner, continued a discussion of Greenhouse started during the first keynote by talking about Spring Social and Spring Mobile. Donald discussed Greenhouse as an OAuth (open standard for authorization) provider, using both an API key (permitting another application to connect to you while running the Greenhouse client from a mobile phone with the Safari browser) and a "secret" key. Access tokens are stored within the browser database, including both the API key and secret key that are both encrypted (the encryption method was not discussed).

Permanent OAuth connections can be made via Spring Security. The first milestone of Spring Social is planned for M1 release later this week. In addition, the M1 release of Spring Mobile is also planned for this week. Spring Mobile provides automatic conditional view rendering depending on the device by which an application is accessed, and from one line of code these different layouts are effective across all pages of the application.

Jon Travis, Spring Insight architect and co-founder, took the stage to demonstrate Spring Insight, which provides monitoring of requests across an entire VMware cluster in real-time, including the ability to easily drill down into requests such as JDBC. During the demonstration, Travis commented that "the concept of the cloud is really open to debate", mentioning that instances of tc Server for example are really "just transient objects that can come and go".

(Note that during the conference, I had a chance to chat with a few SpringSource (and coincidentally ex-SpringSource) representatives during meals, and one individual from SpringSource replied "really not much" to my question as to what makes tc Server different than Apache Tomcat.)

SpringOne 2GX 2010 Day 2:Virtualizing Your Java Applications

Virtualizing Your Java Applications: Best Practices (Justin Murray)

Emerging Technology Track 8:30 AM - 10:00 AM

---

From the conference materials:

In this session, you will learn the key things to consider when you take your application to a virtualization platform, in particular to VMware ESX. The choice of configured memory sizes, virtual CPUs, timekeeping strategies and general virtual machine monitoring will be explored. Best practices will be detailed in each section. An example performance test project will also be shown.

Justin Murray holds a technical alliances role at VMware, where he has worked for three years. His main work at VMware is in helping ISV partners to test, prove and optimize performance of their products on the VMware vSphere platform. Justin also helps VMware's customers with virtualizing their business applications and infrastructure and advises them on best practice approaches to virtualizing Java-based applications in particular. Previous to joining VMware, Justin worked at HP on management software and on Java on HP-UX.

---

From my personal notes:

• Use of VMware ESX (not VMware ESXi or VMware Server) is the focus during this presentation.
• Technically, no changes are needed when moving Java to ESX.
• This session shares insights based on real world customer scenarios by Justin Murray from VMware.
• There are only 7 best practices here, all of which are well documented in the VMware white paper on this subject, although not everything presented in this session exists in the white paper.
• Only about 25% of attendees (by raise of hands) appear to have already started virtualizing Java applications, and a small portion are currently considering doing so.
• The Hypervisor gets out of your way most of the time, passing down Java instructions directly to the JVM most of the time.
• If you follow these best practices, getting within 5% to 10% of the performance achieved without VMware is obtainable.
• There is a large wave of applications currently being migrated to VMware in the industry.
• The classic use case of virtualization is server consolidation.
• The ratio of physical to virtual servers is typically 5, although this number can be much higher.
• About 90% of servers typically run at about 14% or lower of CPU capability.
• Running multiple Java instances within a virtual machine is a better way to use the additional power available while at the same time providing isolation across applications.
• It is much easier to isolate performance problems when using virtual machines.
• Isolation at the OS and JVM layers enables greater flexibility for patch management.
• Rapid provisioning can be performed by storing a "golden" virtual machine in a library and copying for other instances.
• VMware HA (High Availability), DRS (Distributed Resource Scheduler), FT (Fault Tolerance).
• It is recommended that only 1 to 3 JVMs be running in each virtual machine, although Murray has seen customers run dozens per virtual machine.
• Java is probably the easiest platform to move from physical to virtual.
• The Hypervisor is essentially a customized OS that specializes in hosting virtual machines.
• There are 3 layers of memory that support Java: physical server memory, virtual machine memory, and JVM memory.
• Do not overcommit your ESX server.
• The ESX Hypervisor has no idea that memory references are associated with Java.
• JVM garbage collection acts the same way when running on a virtual server.
• Transparent page sharing enables memory overcommitting, but Murray advises to stay out of that scenario when using Java.
• Memory management between guest physical memory and machine memory is now handled by the latest hardware.
• Use the "very, very latest" hardware for Java systems - right now the Intel 5500 and the AMD Shanghai - typical results demonstrate 25% performance increase.
• Extended page tables (EPT) are available with both the Intel 5500 and AMD Shanghai.
• The motivation of ESX is to share as much as possible.
• Switch off the page sharing algorithm between virtual machines.
• Ballooning enables emergency retrieval of memory, but VMware has no idea that it is affecting the JVM.
• ESX has a SWAP file for each virtual machine, but we do not want swapping to occur because of resultant performance degradation.
• The following features need to be turned off: page sharing, ballooning, and swapping.
• How big should the virtual machine be? The virtual machine needs to be sized to leave adequate space for the Java heap and other memory demands of the JVM code, for any concurrently executing process that needs memory from the same guest OS to prevent swapping in the guest OS.
• The memory "Reservation" value in the vCenter client needs to be set to the size of the active memory for the virtual machine, but a problem is that people often do not trust themselves when setting this value, so use the configured memory if you are in any doubt about "active memory".
• Using large memory pages provides up to a 20% performance boost.
• Page sharing between virtual machines is based on content - it is possible that using the same guest OS for multiple virtual machines will increase this capability.
• A single Java thread executes on a vCPU at any given time.
• What is the right number of vCPUs to assign to a given Java process? Perhaps 1 vCPU is all that is needed. It is possible that Java software being investigated is not as multithreaded as one might think. The majority of Java threads should not be in the running state, but in the waiting state or the ready to run state.
• It is not possible to look at the static threads and determine how many vCPUs should be used.
• Generally speaking, it is alright to have more vCPUs than physical CPUs, provided that they are not running at 100% all of the time.
• It is feasible to have overcommitted vCPUs, not overcommitted physical CPUs.
• Run load testing with varying amounts of vCPUs to determine the effect on a Java application - start with the lowest number of vCPUs that is practical.
• More vCPUs is not always better.
• Set limits on real CPU power when maximizing utilization of ESX host with multiple vCPU virtual machines.
• Use vCenter and "esxtop" command. The level of granularity is finer with esxtop - about every 3 seconds as opposed to every 10 to 15 seconds using vCenter.
• Be careful with the amount of I/O logging.
• The "esxtop" command is modeled after the traditional Linux "top" command.
• Use "esxtop" with "netstat -a" to determine any network related bottlenecks.
• Use "esxtop -n".
• Synchronize between ESX host and virtual guest OS with external NTP source for Linux or w32time for Windows.
• Lower the clock interrupt rate on Linux machines by using a more modern kernel if possible.
• Use as few vCPUs as are practical for your application.
• Kernels for best timekeeping: for ESX 3.5 use SLES 10 SP2 (use VMI for 32 bit VMs), RHEL 5.4. (Note: missed recommendations for ESX 4.0.)
• Use your actual application code in sizing exercises rather than representative code or subsets of what you think represents your code.
• For easier monitoring and load balancing, use one JVM or a small number of JVMs per virtual machine.
• Use "esxtop" output data to see where resource consumption occurs in your Java application.
• What you lose when having more than one JVM per virtual machine is that when you use vMotion you will not know exactly which JVMs are being moved.
• White paper will be updated again in the next few months.
• A tool called "Capacity Planner" can be run against virtual machines to gather statistics to determine how many can be virtualized without even thinking.
• Capacity Planner monitors context switches per second, disk I/O, memory consumption, and other concurrent process besides Java consumption.
• Use the latest versions of ESX/vSphere and hardware with virtualization assist if possible.
• Latest ESX 4.1 combined with latest hardware can provide as little as 0% overhead - the latest can handle 200k IOPS greater than 95% of Oracle databases in the world.
• In some cases, virtualized platforms have even greater performance than physical counterparts.
• Performance brief white paper.

SpringOne 2GX 2010 Day 1: Keynote

Just returned from the first day of the SpringOne 2GX 2010 conference held at The Westin Lombard Yorktown Center in the heart of the Lombard / Oak Brook, Illinois business corridor. The complete session schedule for the week (Tuesday evening through Friday afternoon) is located here.

From the conference materials:

SpringOne 2GX is a one-of-a-kind conference for application developers, solution architects, web operations and IT teams who develop, deploy and manage business applications. This is the most important Java event of 2010, especially for anyone using Spring technologies, Groovy & Grails, or Tomcat. Whether you're building and running mission-critical business applications or designing the next killer cloud application, SpringOne 2GX will keep you up to date with the latest enterprise technology.

Featuring over 100 presentations delivered by development leads and published authors on the Spring, Groovy/Grails, Tomcat and Cloud technology today, it's the ideal place to obtain critical skills to help you build, run and manage tomorrow's software solutions. Plus you'll meet and learn from open source leaders who drive innovation for these technologies.

There exist several different tracks of sessions during the conference this week, and several work colleagues and I will be attending sessions during various periods of time that interest us both professionally and personally. For example, I am personally interested in sessions pertaining to moving applications to VMware products due to the virtualization work I am performing at my current client.

This evening I attended the dinner and follow-up keynote address led by Rod Johnson, founder of the Spring Framework. Johnson is currently General Manager of the SpringSource Division of VMware (SpringSource was acquired by VMware in 2009). Along with Johnson, a few other individuals spoke directly to specific products within and around the SpringSource lineup to provide a preview of the sessions.

According to Johnson, there are twice the number in attendance this year than last year. The three platinum sponsors this year are SalesForce, Google, and Accenture. During his presentation, Johnson commented through a series of slides that it was especially difficult to arrive at a theme for his keynote address, due to the high amount of activity in the last year and a 60-75 minute limit.

Of course, Johnson was working up to a theme that he had already chosen, but the short-lived suspense was a winning formula for the time he had available to do so. In working up to the theme, Johnson indicated that the keynote could have been about any of a number of topics: VMware vFabric Cloud Application Platform, GemStone GemFire Enterprise Data Fabric, the software associated with the recently announced UID for 1.2 billion Indians that utilizes RabbitMQ, Spring Insight in tc Server and integrated within SpringSource Tool Suite, Grails, GORM (which is being extended to support non-relational databases, resulting in a possible name change), Spring Framework 3.1, Spring Web Flow 3.0, and / or Spring Integration 2.0.

However, in searching for a topic, Johnson came upon the realization that the Spring Framework is almost 10 years old after discovering that RequestHandledEvent is the oldest class in the Spring Framework, dating to January 17, 2001. Because of this, Johnson arrived at the following theme: "Spring: Toward the Second Decade".

Johnson repeated the refrain throughout the opening keynote that Spring core values have always been portability, productivity, and innovation. Portability in the past essentially pointed to choice of application server to which to deploy, and over time it became clear that Apache Tomcat was the most popular choice. However, Johnson indicated that we need to view portability in the present day more broadly.

Spring abstracts business logic away from the deployment environment. According to Johnson, we need to think about increase in productivity in terms of both the development stack as well as the process that is used for that development (Grails and Spring Roo were sited during this part of the discussion). We need to address how developers work, to be effective throughout the application life cycle.

Lead developer of SpringSource Tool Suite (STS), Christian Dupuis, followed this discussion with a demonstration of Grails development using STS, to which he commented that STS provides Grails development efficiency far greater than what was available two years ago. Apple afficianados might be interested in knowing that yes, he used a MacBook for the demonstration.

Johnson then discussed two recent developments available with Spring Roo 1.1: database reverse engineering and GWT development through SpringSource collaboration with Google (to which Johnson also commented that there are present many Google developers at the conference). The database reverse engineering made available uses only standard (i.e. non-implementation specific) JPA annotations, and supports round-tripping so that only pertinent changes are made to the code when the database changes.

After a brief mention of the Spring Payment Services project, Johnson reiterated that innovation has always been important to Spring, and indicated that "the world of IT is fundamentally changing". Requirements have changed because among other things it is not about the traditional browser anymore, and there are are higher expectations with responsiveness. And tying into the underlying marketing theme of the conference, Johnson quipped that "Spring is the Java programming model for the Cloud".

A demonstration of SpringSource Greenhouse, apparently a reference application driven by Spring products, was then given, although a portion of the demonstration did not work due to lack of network connectivity. According to the presenter, the entire Greenhouse stack consists of Apache licensed software, and the client is now available via the iPhone App Store.

After the demonstration, Johnson returned to discuss the support for NoSQL databases by Spring Data, and provided a reminder that NoSQL no longer means "no SQL" but instead "not only SQL", to which I was reminded of the claim by Sun that JDBC officially does not stand for "Java Database Connectivity". Spring Data provides support, for example, for different types of data other than that residing in relational databases, such as key-value, column / BigTable, document, and graph.

Johnson discussed Neo4j partially because of the his code contributions to the product. He briefly touched on the fact that there exists trade-offs between different types of data stores, mentioned that Neo4j is "very high performance", and that its sweet spot revolves around social networking, bioinformatics, fraud detection, and MDM (although no detail was provided behind any of these applications).

The CEO of Tasktop Technologies discussed the missing links that his product provides, as well as the Code2Cloud service to be provided by VMware that link the developer desktop (Grails, Roo, STS), software development lifecycle (source control, issue tracking, builds, continuous integration), and cloud deployment. The CEO indicated that the time spent configuring software can be high, and although it might be fun at first, developer time can be better spent delivering business value rather than worrying about infrastructure. The GA for Code2Cloud is planned for 2011, with a forthcoming developer preview.

Johnson concluded by communicating to attendees that while Spring is tackling new challenges in a changing IT world, the mission of Spring remains unchanged.

The following are some additional photos I took during dinner while the conference halls were empty.