Transparency in Software Development

Some days ago, I wrote about a QCon 2008 session where Erich Gamma spoke about transparency and how it is related to the IBM’s Open Commercial Development model (OCD). As I have been involved since last year as a beta customer in one of the projects where OCD is been applied, the Rational Jazz Project, I want to discuss with all of you some thoughts and opinions about this software development style.

First of all, and just to be clear, I’m not going to talk about which is the license model behind OCD. The words “Open” and “Commercial”, when seen together, produces some unexpected chills and thrills, and they have generated some controversial discussions out there, mainly in the open source community (maybe, as Stephen O’Grady points out, it will be more accurate to characterize this as transparent development). In the case of the Jazz Platform, there is also some confusion, because we don’t know if IBM is going to release it as an open source software and then develop commercial products based on this platform (like Eclipse), or if they, both platform and products, will remain as commercial products. I vote for the first option, but the word “commercial” in OCD suggest me the second one.

Instead, what I’m going to talk about is how transparency in a great feature in the software development process. So go ahead.

During my career, I have dealt with lots of products, from both open and non-open source software providers. One pattern that I always find in traditional proprietary software is that you never interact with the development team; there is a barrier between you, the customer, and the vendor’s developers. If you need to report a bug or to ask for an enhancement, you can only interact with a service desk. Usually, they have a support web site, where you can see your own tickets, but you can’t see any other bugs or enhancements reported by others companies. You never know when they are going to deliver a solution for your problem (except if it is a blocker), which will be the way they are going to implement your enhancement, if there are more people interested in some enhancement, … You can only check if the bug is fixed or the enhancement implemented when the vendor delivers a new version of the product, and, sometimes, results are not what you wanted. Furthermore, sometimes, you will have to deal with lots of useless questions, mainly due to misunderstandings between you, the service desk and the development team. This is what Erich Gamma calls “Swiss bank approach to software development”.

This firewall between customers and developers is really very frustrating, not only for the customers, but also for the developers. Some companies try to supply this lack of communication organizing user’s conferences (where you can meet some developers), meetings with whatever worldwide VPs, or through a customer advocate. In some cases, frustrated users set up unofficial forums to share their problems or to try to join forces so that the vendor accepts an enhancement. They try to establish some kind of user’s community, but without the vendor involvement. In my experience, and without intention to offend anyone, you will get lots of nice words, but you rarely archive a real solution.

With open-source products, there is a really different way of relationship between customers and providers. There is an open participation and customers can influence easily in the development process in several ways. And I’m not talking about having access to the source code, which is important, but also having access to the bug tracking system, the development mailing-lists, user’s forums, and, in some cases, the development plans, all of them maintained by the development team (fewer misunderstandings). This well-known transparent and collaborative model usually produces enhanced feedback, which leads to deliver better products (in terms of user’s expectations). It’s about archiving customer value, instead of vendor value.

This is the same interaction I have found while working with the Jazz Project. I have had access not only to the source code but also to the latest integration builds (so I can check how my enhancements are implemented), a wiki with technical information about the platform (if you care about the extensibility), a community forum, the development plans and a dashboard to monitor the health of the overall project. I have had also full access to the issue tracking system, where I can submit my own bugs and enhancements, but I can also see which other enhancements are requested by other customers (and to enroll them if I found someone interesting), in which version are they planned … Summarizing, full transparency in the development process. One of the consequences is that I’ve felt, and this is personal and subjective opinion, more involved in the development process, more biased towards submitting enhancements and more confident about future problems that could appear. This feeling is nothing new if you have previously worked with open source projects, but it is something strange coming from an proprietary product.

However, there is a huge difference between open source and OCD models. While in open source software you can contribute to the code base by fixing a bug or improving some features, in OCD it is not clear which will be the contributor’s role. It will depend on the license model selected, which, in turn, it will establish if there will be a vibrant community and ecosystem outside IBM or if there will be a vibrant IBM’s customer community. Anyway, if the final decision is to keep the software as a commercial product, the transparency applied in this model it will represent a great improvement in the proprietary software development process, for both customers and vendors.

But after using this software development style for some time, I believe that this model it is not useful only to software vendors, but it also could be applied to any IT department, especially in big enterprises, in order to improve their software development process. I also believe this is one of the objectives pursued by Rational Team Concert, the first product based on the Jazz Platform (I will talk about this product in future posts). But this is something that I need to try by myself in the company where I work. As most of my readers already knows, I am in charge of the application developments tools in one major Spanish savings bank. Looking through the development process we use, I am sure that if I ask the users of the tools we develop (our internal customers) how much transparent are we, they are going to complain me. Although we meet periodically, it is hard to achieve transparency only with meetings, we need to adopt different and innovative approaches, the ones I have told you in this post.

And finally, although this is what I honestly think about transparency and OCD, I want to hear other opinions. Do you think this is a good software development model for proprietary software? Do you think this model could be applied inside enterprise firewalls?

links for 2008-04-29

QCon London 2008 – Summary

Last month I attended the QCon London 2008 conference, one of the best conferences about software development. I’ve been very busy after the conference and I didn’t had time to write my thoughts about some of the sessions I attended until now. In the meantime, InfoQ, one of the organizers, has published a worth read post with some views and perspectives of other attendees who blogged about this conference. Anyway, here they are my notes:

How Eclipse changed my views on Software Development – Erich Gamma

Erich started his keynote explaining the Eclipse evolution, from its inception in 2000 as a closed project, the reaction from the development team when IBM decided to release the code in 2002, the success of the transparency model, to the design of the Jazz Project in 2006 as a team collaboration platform to integrate all the best practices learned during the years of the Eclipse development.

He talked about how transparency and accountability added an incremental value to Eclipse, and how it’s related to the Open Commercial Development style, an hybrid development model that takes aspects of both the open and proprietary development models, something that IBM is applying to the Jazz Project and to Project Zero. He said that OCD is more than publishing the source code, it is an open, transparent process, from feature requests and planning through delivery. BTW, this model is very criticized outside IBM due to some misconceptions (developers works for IBM for free).

He described some best practices applied during the Eclipse development, summarized as “It is about being continuous: Continuous iterative and adaptive planning, continuous design/refactoring, continuous integration/testing, continuous delivering/demos, continuous feedback, continuous learning”. It’s what they call the “Eclipse Way”, some practices from all kinds of sources (Scrum, RUP, …) underpinned with values (for example, ship quality on time). But he also said there were some pain points, specially with some boring and painful tasks, and the lack of a integrated tool set.

Then, he explained the Jazz Project, which goal is to be a scalable, extensible team collaboration platform for seamlessly integrating tasks across the software lifecycle, and he finally did a demo about Rational Team Concert, the first product based on Jazz, and asked us to try it by ourselves at the Jazz.net site.

Amazon Services: Building blocks for true Internet applications – Jeff Barr

Jeff, Amazon’s senior web services evangelist, summarized in this session the different services offered by Amazon focused on Cloud Computing. He explained which are today challenges for a company that operates globally: data centers, bandwidth, operations and scaling. Then, he explained in detail the utility computing services available to users:

He also said that, unlike what many people think, most users who use their services are large companies. He gave the example that many of the Fortune 500 companies use Amazon’s infrastructure services to run their development environments.

Keeping 99.95% up time on 400+ key systems at Merrill – Iain Mortimer

Despite the session title, Iain, Chief Architect at Merill Lynch, talked about how Merrill monitored their systems (about 344 tier 0 & 1 globally disperse servers). Two interesting notes:

  • They implemented their own technology, as none of the vendors was able to guarantee a 99,95% SLA (eat their own dog food).
  • They monitor 9 billion messages a day.

Born to Cycle? An Agile Approach to Working – Linda Rising

Funny session, with lots of participation and a great discussion.

Basically, Linda explained that humans are not designed to be linear, instead we act by pulses: we move between energy consumption and the renewal of the energy consumed. Therefore, we must be able to manage our energy, not our time (see the article “Manage your energy, not your time“, Tony Schwartz, HBR, October 2007). If we can find a balance by establishing a regular rhythm of work and rest, then we will have a higher productivity in a more sustained way. She gave the example of setting four 90-minutes sprints (like the REM sleep cycles) a day, where, in each sprint, we have to concentrate on the work to be done without allowing interruptions, and then rest for 20 to 30 minutes. Anyway, everyone must find his own cycle.

She also explained that if you switch your attention from a primary task to a secondary one, then the time it takes increases 25%. The audience answered explaining that this was a nice statement, but hard to be done. What must we do with email, phone calls or IM interruptions? This question resulted to a funny discussion about a study stating that CNN or BBC tickers reduces IQ by 10%, and someone replied saying that smoking marijuana only reduces IQ by 5%. Session conclusion: is better to smoke marijuana than to watch CNN!

REST: A Pragmatic Introduction to the Web’s Architecture – Stefan Tilkov

Stefan did a great introduction to REST. First, he explained that there are 3 different definitions for SOA:

  • An approach to business/IT alignment: driven by business instead of technology, relying on strong governance and implemented using any technology.
  • A technical architecture: service oriented with clearly defined interfaces, and could be technology-independent.
  • Web Services: business data as XML messages implemented using WS-* stack.

Then, he explained 3 different definitions for REST:

  • An architectural style (the right one): what appears in the Roy Fielding’s doctoral dissertation.
  • The web used correctly (aka WOA or ROA): to use HTTP, URI and other Web standards “correctly”.
  • XML without SOAP: send plain XML via HTTP violating the Web as much as WS-* stack.

After this introduction, he explained the basic principles of REST with some nice examples. He finally stated that there isn’t any REST vs SOA war, it is REST for SOA. There are two visions for SOA, to use REST or to use WS-*. The difference is on the technical layer and on their roots:

WS-* roots = The Enterprise: “A gigantic, uncontrollable anarchy of heterogeneous systems with varying quality
that evolve independently and constantly get connected in new and unexpected ways.”

REST roots = The Internet : “A worldwide, publicly accessible series of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP).”

If you are interested in this presentation, Stefan has put the slides in his blog.

The Cathedral, the Bazaar and the Commissar: The Evolution of Innovation in Enterprise Java – Rod Johnson

In this session, Rod started citing some sources of innovation: creativity, experimentation, competition and economic motivations. Then, he detailed the J2EE evolution linking with the innovation factors before commented, with particular emphasis on how the standards established by the JCP resulted on the decline of J2EE.

He compared the JCP with two development models: the Cathedral model, software built by relatively few people, with centralized design; and the Bazaar model, many developers, especially linked to Open Source, who lay out their wares. He stated that neither model is a complete solution: the bazaar model encourages competition but may not produce innovation, and the cathedral model is more likely to produce innovation but doesn’t produce competition. He finally said that JCP acts like a politburo commissar (they know what’s best for the developers), creating excessive standards and ignoring existing technologies. Something that it’s actually evolving but that should change much more and much faster if they want to survive.

eBay’s Architectural Principles – Randy Shoup

Randy, eBay Distinguished Architect, talked about 4 architectural strategies they use at eBay:

  • Partition Everything:
    • Split every problem into manageable chunks. eBay uses 2 partitioning patterns: segment databases into functional areas and split databases horizontally.
    • No database transactions (lot of buzz from last year session by Dan Pritchett). Developers must careful order DB operations. And remember: consistency is not always required or possible.
    • No session state, so user session can move through multiple application pools. Transient state is maintained by URL, cookies or scratch databases.
  • Async Everywhere: use asynchronous processing as much as possible, applying message dispatch or periodic batch patterns.
  • Automate Everything: it is better to use automated systems to manual systems. Example: automated tool executes staged roll out, with built-in checkpoints and immediate rollback if necessary.
  • Remember Everything Fails: assume every operation will fail and every resource will be unavailable, so build all systems to be tolerant of failure. eBay enforces that every change must have a rollback plan, because they roll out their entire site every 2 weeks (16,000 application servers in 220 pools).

Functions + Messages + Concurrency = Erlang – Joe Armstrong

Great fun with Joe’s session, the inventor of the Erlang programming language. He satirized about the reasons that a 25 years old language like Erlang is scheduled in the “Programming Languages of tomorrow” track. He told us that Erlang was created by accident, due to the strong requirements from the telecomm industries (severe penalties if the system is unavailable for more than 4 minutes per year).

He explained that functional language is not the most important characteristic of Erlang. What really matters is concurrency and distribution oriented. He gave the example that Moore’s law is reaching its limit, and how after a 52% power increase in each new CPU architecture prior to 2002, now we are seeing increases of only 20%. He explained that computer architectures are evolving towards: multicore (without success, because applications are still running on a single CPU), cell computers (hard to program) and network on chip (NOC). He also discussed the significant decrease of new CPU’s power consumption: 850 KW for 1 Tflop in 1997 to 24W for 1 Tflop in 2007.

After that, he explained the Erlang’s excellences to run on multicore systems, essentially using the Actor Model paradigm, and the ability to be a fault tolerance language. Finally, he said that every year we will see how sequential programs will be increasingly slower, and for that reason, it is important to be prepared for concurrent-oriented languages.

links for 2008-04-23

links for 2008-04-22