A fistful of quality code: me and my colleague

The title can be more appropriate for a Spaghetti Western movie but is appropriate in each situation pair programmer are surviving theirs daily's milestones enjoying work and maintaining a good environment outside them. "Pair programming" is identified by two words: Pair and Programming. Every developer knows exactly what is programming, but a pair requires some confidence with humans too. In this post I'm focusing on the Pair word of Pair Programmers, analyzing some successful factors like the Rhythm while working.

Like two cowboys a pair must work with a single objective every day, watching each other and helping each other; the external environment is like the desert with rolling Joshua trees and with condors flying, waiting, and watching for the next lunch hopefully with someone "freshly died".

Imaging all this with a Sergio Leone's music that is creating a more characteristic environment, where the rhythm is perceived watching the movie and listening the drum.
Two developers are in the same situation: they help together in finding the best solution for the daily milestone and they need to find out a perfect rhythm.
Like in a movie, some of them are the principal actor, and the other is helping in surviving the scene taking care about the stress and trying to keep her safe from external interrupts.
The main actor in a pair is the one who's typing on the keyboard and typically writing the line of code. In terms of development perspective the secondary actor has to discover bugs, to seek for documentation, to write documentation, to diagram, etc. While taking care of human feeling, the counterpart's job is to help the principal coder in doing things including stress management.
She has to know when it's time to take over and switch the scene acting as principal actor. The frequency of a takeover implies the actors to watch each other, taking care about the health of the pair and trying to keep it good every time.

This is reflected on the quality of the code produced: every scene is played by the less stressed developer. Thus, the other can relax a little bit helping the next small iteration.

In this post I've examined three intra-personal factors that help a pair in staying consistent and durable over time:

• Rhythm: developers play the scene and the rhythm too. Rhythm translates is directly related to speed team. Without rhythm stress increases in one developer and low commitment increases on the other side. This is against the milestone.

• Watch the watcher: developers should watch them as Person and not as developers; programming skill is confirmed line over line, and more humans' behavior (like stress) can easily hide. Watch the watcher if you want to be watched, is a protection guarantee for every developer that would like to work actively in a pair preserving her health prior to the colleague health.

• Takeover when need: avoid to much stress exposure for your colleague? In software development stress is the first cause of low quality. Being the principal actor confuses the main developer and sometimes can drive to the wrong direction, then frustrating and then stress. When your counterpart is loosing her speed, grab the keyboard, and continue typing (of course at your speed). You'll notice that this rapidly debriefs your colleague making her reacquiring her rhythm and then asking the keyboard again.

In a next post, I'll discuss about the relation between rhythm and speed in software development.

2.0 series: what is the natural evolution of interaction design?

Interaction design is a technique improving the web usability and user centered design to identify what is really need in a 2.0 online service and what can be forgot. In our tangible word this is already done by who's marketing goods and who's facing the customer directly. I'm thinking about Starbucks that sells coffee in a really good fashion or UPS that is facing customer with a professional front end. Starbuck's and UPS's employees are the direct face of the company to the customer, and they are a mix of professionalism and marketing. They know exactly what to wear, what to say, and how to make comfortable a situation with a customer.

This is coming into the Web Space, and has been discussed a lot at the Web 2.0 Expo in New York last week. The web 2.0 is improving with interaction design that focuses on doing only what a company is thought for and on forgiving extra services discoverable on the market. Interaction Design from Joshua Porter is the first step in this scenario, and now Christopher Fahey from Behavior Design is talking about Seductive Design where 2.0 services seduce the end user.
I think that is on top of the interactive design's principle from Porter, and it is introducing some marketing concepts in software development. In classical corporate marketing focus is to make some corporate services appealing and sexy. The same is happening with the ideas in seductive design where the focus is to create a seductive interaction with the user mixing images, videos, and behaviors. This with style and creating the desire and then pleasure that the service is creating. Services user experience is an emotion for users that are paying for a system. Everything is thought as potentially something new; the way to attract, to create suspense and to delivers a service in a professional way trusting who's at the counter side. Imagine a future's Apple product, is it in your imagination an unusable product, with bad colors and high price? That's because Apple has created a Product Service Factory that innovates in a real and sexy way.
All this is coming with Seductive design where marketing is becoming a cross culture like software development is crossing to all the roles.
Services will attract more users more they're sexy, and users stay with the provider for the quality of the service and for the trustiness that the company has created.

Do things with style? Is it still possible?

Design has become popular in several context, and it is applied in applied arts, engineering, architecture, and other creative endeavors. Design is something cross to all the things around, and a good design is simply perceived without too much understanding going straight through the final objective.

Last years I did lot of things spacing from developing, architect, designing software to put customer ideas to market and I've learned lot of things about each activity I performed: for an excellent result every activity should have a good style and a good design. But, what a good style and a good result? To fast figure it out, if we think a picture of a car from a kid and from a designer like Giugiaro, they're, both, drawing a car with four wheels, and engine, some seats etc., but the main difference is that Giugiaro's car will seem more accurate and beautiful that the kid one. That's only because Giugiaro is a professional designer and the kid is just playing with a pencil and a sheet. Now, switching the metaphor back to everything we delivered in the past we can focus on the result and on the next improvement in term of style. Here is a list of key point when I'm doing things trying to figure out "a style":

• Build only what is absolutely necessary
  
  There is lot to do and if we do more than our potential, maybe we'll reach the goals, but lacking on style and quality. So, one of the first statement, when I approach something is to find out what cannot be done to stay focused on small portion and put all the energies there. This trend is notable in 2.0 where services focuses only on small things giving an idea of lightness and the refinement process improves iteration over iteration.

• Quickly turn beginning users into intermediate
  
  Think about a sexy girl! She creates interest without telling things; the viewer is not reading papers, documentation or watching podcast to be attracted by the girl. She is turning a beginner user to an intermediate fast creating the correct interest in doing things and maintaining the learning curve small. This is what in Agile Development, we call self documenting software: if it is sexy and appealing for developers can be learned fast without too much archetypes around: like a sexy girl.

• Prevent errors whenever possible and handle the errors we cannot prevent gracefully
  
  Good style is something appreciable outside the designer and style should be perceived rapidly. You can get wrong while designing, this is why on every small increment the heart of design should pulse to his target to check if it is good for it or not. It is not a way to pre-sell, it's a way to anticipate problems gracefully. Shouting every small iteration makes a good style growing.

• Reduce and refine interactions and task flows until even the most complicated applications are clear and understandable
  
  Refinement focuses on making things implicitly clear, in the way just watching them for few times, they're understandable. This is what I do, when I seek what cannot be done. This is not a technique to postpone work; it is a method to check if something is still available and need to emerge from the already available resources. Good style is made of few things because the huge variety of things is gone implicitly inside the design itself and is easily discoverable and understandable.

• Adopt metaphors, better visual metaphors to explain the complexity and bring it to a human comprehensible level
  
  Metaphors are the key to find out what is implicit in a context, and only with metaphors you can focus on what is really not clear. When thinking an archetypes a metaphor is a good statement to better understands, picture or diagram the archetype itself.

• Ignore the demand of users and stick to a vision
  
  Improvements are done through brainstorming and brainstorming should be stick to a vision, a common vision. It's important to stay focused on the purpose, and not to switch over ideas every user express.

These are only a bunch of rules; I'm learning from my experience. Surely some new rule can come in the next future.

Some 2.0 anti patterns in Development As A Service

The main intent of the Software Development As A Service, is to outsource development to stay better focused on what is really producing value in the starting 2.0 pioneer's company.
A fresh and new idea is the real trouble of a Startup and most of the energy should be spent on that direction, while other problems are addressed trusting the services bought depending on the Service Level Agreement defined.

After a good experience in the 2.0 era in developing several online communities from the Service Provider point of view, I think it's time to share what I'm learning and the mistakes I'm doing in facing this kind of opportunities.

I'm calling those experience anti patterns because they are a good representation of what can be optimal in theory and is really ineffective in practice if the 1.0 culture is mixed with the 2.0 culture.


Embrace Software Development Company processes

Having the idea to implement all the software by delegating to a Development Provider, comprises the adoption of all IT culture of the engaged service provider.

This can be obvious a really proficient until the Startup Company is trying to figure its own development process asking the service provider to embrace and focus on its way of doing things.

This approach drives to two main drawbacks:

1. Startup company is now focusing ideas to development process that is not really creating revenue for its business;
2. Software development company is forced to change the way they do things, learning a new option in software development and focusing on the customer's process intention instead of customer business needs.

This moves the Startup's focus from the Business idea to development spending energy (and money) in thinking on gates instead of thinking on the time to market for even easier idea and Software development to produce process's artifacts (reports, well-formatted documents, etc.) instead of good software.

Focus cannot be easily restored because the current focus is to be compliant with the process. When choosing a Software Provider Company, a 2.0 startup should put in its decision table.
The way the provider works is a good point of evaluation and must be agreed with the Startup Company to avoid the process as the next collaboration's problem.


Identify a Service Level Agreement on each Service

Startup and Service providers should agree on both parties on how they're allocating or delivering services request.
A Startup Company should create milestones that bases the professional relation. Milestones are business objectives that potentially influences the ROI of the Startup Company, and Servicing company should base their SLA depending on the milestones objective.

A SLA identifies an interaction model where parties agrees to implement something that is really valuable; this creates a conversational and honest model where things go in the same direction and both.
The parties are focused on the goal. Without a SLA, a Startup Company is shifting to an investment protection system paradigm where energy are spent to avoid money loss. Without a SLA, a Service Provider focuses on service's accountability instead of service providing.
The more the Service Level is the more is the price for it. This simple rule can be extended in: the more on the service level of what is really indispensable the more a company can pay for it.


Easiness is not simpleness

A 2.0 application is a big mash up of Services around the network; in the 1.0 culture there is the idea of System Integrator that is responsible solely to do a kind of component integration.
Meanwhile in the 2.0 culture the idea of system integrator is hidden by the idea that services are available on standard protocol and then easy to integrate because it's just a javascript call or a bunch of ruby on rails lines.

The complexity of integration in 2.0 is the same of the 1.0, every integrated platform must be reliable, must work and have custom development associated. The big difference from 2.0 and 1.0 is that 2.0 integration is through services starting from the presentation tier, while in the 1.0 everything is hidden in the integration tier.

A 2.0 approach is to make the user interaction easier by leveraging on all the available technology: that's really complex and require great skill and good professionalism.


Re-DO to DO approach: talk and listen together

2.0 culture is pioneering, and fresh ideas are often not clear to be written as a strict requisite. It's easy to misunderstand what the customer is explaining and what the Service Provider is understanding.
Small iterations and a continuous conversational approach must be established to achieve the same goal. Customer and Service Provider have to thing that the counterparts are producing value day by day discovering things that are still unknown.

A 1.0 approach drives the customer to outline all the requirements predicting what will be, and in the most cases failing in some aspects. Failing means: redo the same thing. Consequences of the "redoing mindset" will be unable to launch the Startup's Services at each milestone. Redoing several times, breaks trustiness and team happiness.

A 2.0 approach is based on continuous improvement on things and from the failing paradigm moves to the Learning paradigm. Continuous improvement switch the mindset from stable services to perpetual beta services.


Conclusions

These are some of the things I've found from a first retrospective with all the involved players in my experience from the Provider Company. I'm sure this is only a starting point for the 2.0 anti pattern catalog and more will come from the experience.

A blog for a Startup 2.0 website?

Having a website today is producing some value and not having it, is creating lot of penalties. Traditional enterprise web modeling has lost the concept of static websites for a more dynamic approach where the life of the company is perceived through the web too. Different navigation from the old fashioned menus is needed, user should move on the web site and interact with the website directly by categorizing and commenting all the contents on the website. Blogs are a good way to implement all those functionality in a modern way. Visitors should be able to browse content thought their interests and not through what company want to tell. That's why content's tagging is more important than categories and menu.

A blog entry can be seen as a content, with several information linked; hyperlinks are a good example on the power of linking things and menus are good samples on how contents can be organized.

But, this in direction and through the monopoly of the corporate. Thinking 2.0, contents are coming out from who work and even better can come out from the visitors too. External services like delicious or technoraty enable people to link pages and shares them across the net by tagging them. Thinking of contents as blog entries from the editor community, and tagging as an empirical way of organizing content lets a 2.0 start up company to find what is really important and how visitor are identifying it through the tagsonomy related. A user can browse the site, thought as a set of entries, in different ways starting from the old one through category moving to an editor tag browsing and facing it at the end to the visitor's tag apposed.

This is only because web site's fragments can be referenced with some tag. This can glues either an old fashioned web page, and a dynamic new page where fragment are linked by tags more significantly for the current visitor.

Blog engines like wordpress are fully customizable and have dozen of plugin to interact with entries, tags and outside services like delicious or technoraty.

The next move on the corporate website's chessboard will be to migrate the standard website to a custom blog having some of the blogging featured customized and having the community to work on it editing and tagging content's fragments.

Services vs. Components: Is it a death match?

There's lot of misunderstanding between Components and Services: components are something that aggregates a product for a business behavior while Service is what is doing real business and it's remotely usable from who is really interested in the value added the service is producing.


Nowadays the term service is in every modern acronym (SOA, SAAS, SLA, etc.), and there is non clarification on what is a service and how it differentiate from old fashioned terms like Components.

The term Components come from the manufacture's industry where all those modules are used to build things. It doesn't matter if a car engine is manufactured by Ford or by Subaru, it is produced reusing some of the same components and it is not implemented from the scratch.
During the last years, the Information Technology approach has been to watch other industries and to try to implement all that has succeeded into software. Like in the manufacture, software components are a unit of software that provides business or technical functionality.
Typically they're self-contained and independently deployable. Thinking about a software component we're used to think to:

• a specification (analysis and design) that defines the scope of the component;
• an implementation with any invokable interfaces;
• a module to be deployed (an EJB, a WAR, an EAR, a DLL, etc.).

A component offers its implementation through an interface, that's the unique way a component should be used.

Differently services are focused on satisfying business needs, on a consumer/producer paradigm where the service is producing something valuable for the business. A service can be thought as a set of components and differently from components. A service can be something else than a component. Instead of having an interface service allow the concept of API on different protocol and they can act synchronously or as event's agents.

Another big difference between Services and Components is the way they're reused. Going back to manufacture Components is stored on the shelf and is taken and deployed when necessarily.

Service, in an opposite direction, lives somewhere and is addressed to be used.
It's like going to the post office to send something instead of creating a post office in house.

An approach with components requires a new deployment, new hardware dimensioning and integration while a service approach is only focusing on integration.

What is making the difference?

The way the architectures are thought is making the difference, thinking SOA is benefiting the reuse of value added services and is accelerating the way software is implemented. Every architect is implementing a system, should think a way to make the application addressable and callable by other Service around the network promoting Service Reusability. In terms of business, Service reusability creates a new approach of doing business where specialized companies are providing something that produces real value as a service and is offering a large scale the service at a low price. Google, or salesforce.com or Amazon is again an example of the power of thinking SOA.

Is architecting a 2.0 extendable appliction the same old story?

Architectures are following the way to be extensible, flexible, and easy to be maintained. A 2.0 scenario makes things growing on demand, starting with a small set of features and growing to a huge application with lots of other integrated application (mashup) and complex business logic. Everything shall evolve and redesigned time over time, feature over feature.

The best approach in delivering a modern application is to consider the application itself as a big mashup of the application. This implies, again, a multi-tier approach where there is something in the middle tier that executes something valuable and there's something in the presentation tier that orchestrates business behavior.
Thinking in the way we thought with Enterprise architecture based on EJB and other complex solution, the separation was into the presentation tier, the business tier, and the integration tier.


All the components should be divided into one of the above tears, depending on their roles, and responsibility inside the architecture. Why the separation of roles? Separation of roles can tune the architecture in several point with lots of combination. By implementing modern architecture on social communities, I've found important in differentiating the business tier from the presentation tier: as I do in enterprise architecture with high available technologies. Things and names changes, but the result from the architecture should be the same: having and extendable and flexible system.

The key concept in modern thinking is to separate services their API from their "social interaction" promoting a Widget as a visual coordinator of something is happening backward.




This brings out a reusable API, a first use of the API that is the Social Application and the versatility of the architecture. Having modern API exposed in several formats including JSON restful services, this enabled the idea on having the integration tier as the "presentation tier" or on the old fashioned presentation tier. The modern presentation tier is called Mash up and is really adaptable depending on the needs. If it is required that a machine should do something on the integrated platform (viz. flickr), it can be done at server-side as a restful service. If it is required to operate with some integrated platform visually, it can be called directly from the presentation tier. Yes, this is the first example of how flexible can be an architecture: I can choose to do integration on throttling on the service platform or to choose to go strike through the integrated platform directly from the client interface. This is gained only because, the integrated platform has been tough having the concept of API and that the Social Application is itself a big mash up of those interfaces. Making an API public or private is a tremendous business decision, and should be accurately agreed after heavy consideration. Having a public API makes other the reuse idea instead of the feature copy idea; this requires the company, should also have a clear policy on how integrators can use its API for their mash up. This will be a next big opportunity that 2.0 will create. Stay tuned.