L&C - Learning and Coolness

L&C is the software methodology we use to develop Sneer, the sovereign computing platform.

 

Douglas Giacomini, myself, Sandro Bihaiko and Rodrigo Bamboo in Guaratuba, Brazil

Our project has certain peculiarities: it is a funded, open source project and we have a small team of up to 4 developers plus occasional contributors. Our technical lead also knows a lot about the business. That is not the case in the early stages of most projects but it is often the case after a few months.

L&C is guided by two values:


1) Learning

Learning supercedes the XP values of simplicity, communication, feedback and respect:

• It is much easier to learn simple things than complicated.
• It is impossible to learn and teach without communication.
• We can only learn when we get feedback for the things we do.
• Learning sets the humble and respectful attitude we need to approach our peers, our users and the code.

Learning requires communication, simplicity, feedback and respect

Learning also gives us, once and for all, the requisite understanding of what software development actually is. Software development is not "ball dancing", it is not "driving a car" and it is certainly not civil engineering. Software development >is< learning.

Building a replica of a shopping mall, for example, with the same construction crew costs 90% of what the first mall cost. Producing a replica of a software product with the same team costs a fraction of what it did the first time because the team already knows how to do it.

The source code to any particular software system is not a product of what a team has built. It is an expression of what the team knows. That changes everything.

There are heated discussions in the industry as to whether pair programming and moving people around is productive. The notion that learning is really our goal renders all these discussions void.


2) Coolness

Coolness supercedes the XP value of courage. One cannot be a wuss and be cool at the same time.

Igor Arouca and my foot - Hammock pair programming in Curitiba, Brazil

We like working with excellent programmers, true software craftsmen, and excellent programmers like doing cool things.

Our team:

• Learns new things
• Invents new things
• Makes a difference
  
• Writes its own tools and languages when necessary
• Travels
• Parties
• Speaks at conferences
  
• Interacts, discusses and challenges
• Engages the community
  

"Pool Programming" - Didn't actually work but we tried it :)

Our team also ships working software. Failing to do so is, by definition, the most uncool thing a software development team can do.

Practices

How does L&C affect our lives concretely? Let's compare it to XP.

We believe it is misleading and arrogant to try and predict the future. Nobody likes doing the following XP things. The insight they give us is no better than an educated guess by a business-savvy project leader and the effort and stress they imply are just too much, so we dropped them:

• Release Planning
• Iteration Planning
• Project velocity
  
• Planning Game

(Scrum is glorified release planning, so we don't do that either)

We also dropped the following:

• Iterations (!)
• Continuous Integration
• Open workspace
  
• Stand-up meeting
• CRC cards

To the remaining XP practices, we added a few things:

• Significant Celebration - Instead of celebrating the Nth sprint (Yay!) we finished, we prefer to travel somewhere nice when a significant business or technical milestone is reached.

• Remote Pair Programming - Skype and VNC. Having the team co-located is certainly more productive, but we want to work with the best developers, wherever in the world they might live.

• Hammock Pair Programming - Ad-hoc wireless and VNC.

Hammock pair programming with Patrick Roemer in Florianópolis

• Team Chat - A chat conversation open on Skype all the time with all members of the team. Has the same effect as an IRC channel.

• Weekly Conference - Same as a stand-up meeting but via Skype.

• Let Your Customers Remind You 

Listening to Potential Users at the Sneer Summit in Curitiba

• The Cleaner - A role specifically allocated to refactoring. There are no fancy discussions about "technical debt", "productivity curves over decades", etc. Refactoring is hygiene.

Jules, Vincent and Wolf, The Cleaner

• Continuous Deployment - Anything any developer commits is downloaded by new users at most five minutes later on the project website. 

• Periscope - We use periscope to emerge occasionally, look forward and ask ourselves: "Are we going in the right direction? Is there a huge iceberg ahead or an amazing shortcut we could take?". That is all we need to know about the future. We plan on demand and simply take the next baby steps in the right direction. We trust our own agility so we don't lose sleep over hypothetical icebergs far, far away. Also, we don't need estimates to "measure" our team's productivity and whip developers that are late. We simply use periscope to look back and answer: "Are we progressing fast enough? How can we optimize our work?"

More than a deliberately designed methodology, L&C is an empirical observation of how we work and what we value.

POJOs Considered Sexy

Transparent persistence, orthogonal persistence and POJO persistence all have the same meaning and imply the same formidable thing:

You get to use objects without worrying about database restraints.

As such, transparent persistence has been a long-sought "holy grail" in the industry. The EJB 3.o Specification (JSR-220) early draft cites as one of its goals:

"Enterprise beans are simplified to more closely resemble plain Java objects ('POJOs') or JavaBeans."

"To more closely resemble" is the kind of humility and respect you would expect when referring to the holy grail of POJO persistence. Appropriately so, it is the only reference to POJOs in the entire spec because, the minute you force it to implement or use an API, by definition, it is no loger a POJO and all its magical properties are gone.

Linda DeMichiel and Craig Russell, though, "Specification Leads, JSR-220 and JSR-243", simply decided to hijack the definition of POJO from Martin Fowler and, thanks to their "A Letter to the Java Technology Community" the new JDO+EJB overhead is now known as "POJO persistence".

Helping out on the "If I can't have transparent POJO persistence, nobody will" front, Rod Johnson and Jim Clark have even redefined transparent persistence:

"Such technologies ... are often said to deliver transparent persistence—the ability for an object-relational mapping product to directly manipulate (using an object programming language) data stored in a relational database."

With that brand new definition, now even JDBC provides transparent persistence!

Notice the "are often said" disclaimer in the quote above. Marketing people can make techies write all sorts of stuff but there are limits to the rubbish they will take credit for.


So What?

If people believe a fake, they will stop looking for the real thing.

To the newcomer, technologies that actually do provide transparent persistence will be no better than grotesque JDO and EJB stuff.


The Motive

Why would these people do something like this?

Many are simpy repeating what these guys are saying out of sheer ignorance. But, from the gate-keepers themselves, one has to expect more than that.

I can't say for sure why they did it, but one thing is certain: "POJO persistence" does sound much sexier than "yet another intrusive persistence API". ;)


Klaus Wuestefeld
Prevayler - "Persistence is Futile"

Database Atrophy

Welcome, :)

I feel we, the software development community in general, are suffering from a condition called "database atrophy" and most of us don't know it.

We are so dependent on the services our relational database servers (RDBMS) provide, that many of us could not live without them.




I believe this RDBMS dominance is causing us to yield but a fraction of the power in our computers.

Object-oriented languages have been around for decades and the next few years, at least, will clearly be OO language dominated. There is no serious contending platform besides Java and .NET today.

Still, the promises of OO, such as high-quality and reuse, are not fulfilled.

As an industry, we are still holding conferences on how to better develop CRUD software and hailing thing like Ruby on Rails.

And the reason for that is RDBMS dominance. There is absolutely no way of doing OO with your live data in an RDBMS.

In contrast, there is a specific breed of aliens on our planet that develops systems of complexity, performance, stability and portability that completely dwarf our efforts, and for a single reason:

Except for storing keyboard control settings and high-scores, they are completely free from databases.

10 years ago, people thought using "data-aware" GUI "objects" coupled to their database was using OO. Today, many people think that using an Object-Relational Mapping (ORM) tool to map dumb data-objects to database records, is using OO. :(

ORMs such as Hibernate, Castor and Toplink are central players in this depressing context of ours. On the one hand, they provide a palliative in the absence of true OO but, on the other, they actually hamper the community by illuding it and giving OO a bad name.

But I believe a brighter future is inevitable:

• OO design patterns are starting to kick in.
• IDEs are starting to invest in decent OO design support rather than database-coupled "RAD" development.
• Open source project are cross-pollinating best OO techniques such as refactoring, test driven development, implementation independence, etc.

Feel free to participate.

This blog is dedicated to denouncing the symptoms and causes of database atrophy and providing a vision of what we can do in full health. :)

See you, Klaus.
"Do You Still Use a Database?" http://www.prevayler.org