We recently teamed up with the good folks at LinkedIn .Net User Group (LIDNUG) to help raise awareness about the benefits of aspect-oriented programming (AOP). On November 3rd, from 9:00 AM (PT) to 10:30 AM (PT), Gael will speak about the problems with conventional programming, give a gentle introduction to AOP, show how it works, and explain why .Net developers should be using it to eliminate crap code from their lives.
Produce Cleaner Code with Aspect-Oriented Programming
Here is the agenda:
- 0 to 15 min: AOP Introduction and Myth Busting.
The session begins with a gentle introduction to AOP and sets the record straight on some common, yet misinformed, beliefs about AOP.
- 16 to 30 min: Live Coding.
Gael shows how to generate more concise and readable code by using aspects to refactor a multi-threaded WPF application.
- 31 to 45 min: Build-time Benefits.
Gael explains the advantages and benefits of build-time weaving compared to DynamicObject.
- 46 to 60 min: Live Coding.
Gael demonstrates how AOP can implement complex patterns for you: e.g. generate all the code behind INotifyPropertyChanged
- 61 to 90 min: Q&A
Gael answers your questions about AOP
Join us next Wednesday, November 3rd from 9:00 AM (PT) to 10:30 AM (PT) via Live Meeting.
Reserve your spot at the LinkedIn .Net User Group event announcement page here:
We look forward to seeing you there.
There’s been some remarkable contributions from the community these last days; so let me write just a few words to introduce them.
Adam Bell released an aspect library that addresses a single concern: caching. In Adam’s own words:
Cache expensive methods calls with a declarative attribute. No custom code required. Configure caching method using unity. Options include In-process and Out-Of-Process and Off. Out-Of-Process uses Microsoft ApplicationServer.Caching.
The project supports declarative cache invalidation. It is released under BSD license and hosted on CodePlex.
For more information about this project, read Adam’s blog.
Unit Testing of Aspects
Michael Collins blogged about implementing method tracing using log4net and PostSharp. Déjà vu? Wait. It’s true that tracing is the “hello world” example of AOP, but Michael gives us a production-ready implementation.
The most remarkable point of this post, for me, is that Michael shows us how to unit-test the aspects using a mocking framework. Very cool!
Many thanks to Adam and Michael for their great contributions!
I’ll be in Berlin, Germany, at TechEd Europe between October 7th and 12th.
I would love to meet some PostSharp users there. If you’re one of those and will attend the conference, I want to hear your feedback: your use case, your experience (positive and negative), your wishes for future versions.
Please drop me an email at firstname.lastname@example.org.
Just a quick note to mention I have just published the recording of my session at the European Software Conference on October 7th 2010: Refactoring multithreading in a WPF application using aspects. It’s real live coding – always a hard exercise, especially after a night with 2 just hours of sleep (the reason being hopefully clear).
In this session, I start from a half-finished WPF application and add three concerns: exception handling, background thread, and updating the status bar. I compare the plain old C# implementation to the AOP/PostSharp implementation.
Enjoy! Comments are welcome on this post.
People caring to do their job
to the best of their ability
to produce a beautiful object.
In my last post, I wrote about the recent interviews I recorded with some prominent software developers in the UK and tried to define what software craftsmanship means.
The most important dimension I could identify was the genuine care for quality beyond what’s necessary to just ‘survive’ in a company, and the conviction that the qualify of software depends on the quality of the people producing it. Therefore, it seems the right way to improve software is to improve software developers themselves, through deliberate practice and constant learning – including what we’re not taught in school.
Every community has a set of “core beliefs” and the points above are, in my view, the core beliefs of the software craftsmanship community. There are two kinds of people in this life: believers and critics. Believers often take critics for enemies, but critics actually help the community to evolve and to grow.
Helpful criticism: this is how we should label David Harvey’s recent presentation at QCon: Danger! Software Craftsmen at Work. David makes several points that are worth our highest attention:
It would be a great shame (...) to see a world in which we as a development community, because we become so obsessed about catas and dojos, apprentices and journeymen, actually lose contact with the businesses that we live in, the people who use our software. (...)
There is a great danger that, as the movement grows, there are parts of our community who will see what we are trying to do here as an excuse to separate themselves from the concerns of the business.”
- The Manifesto for Software Craftsmanship is empty of content because it is not refutable, i.e. it is not possible for a reasonable person to disagree. (Interestingly, refutability of theories, a concept made popular by Karl Popper in the 1930s, is at the foundation of modern science). I won’t address this point here, because I think it is true but not essential.
- The opposition of software craftsmanship to software engineering is pointless and may even give permission to software developers to ignore the lessons of software engineering.
- Metaphors, and the language we are using to describe ourselves and our activity, do matter. The people around us think of a craftsman as someone producing leather bags, not items you can rely on. Although software developers have their own definition of craftsmanship, what eventually matters is the perception of our customers. By choosing inappropriate metaphors, we are increasing the gap between those who build software, and those who use it.
To this list, I add my own point: if software craftsmanship is above all a personal attitude, what shall we do as a community; what is our call to action?
Software Craftsmanship vs. Software Engineering
Pete McBreen, in his seminal book Software craftsmanship: the new imperative, identifies software engineering to the waterfall development methodology. Instead of associating project failures to a specific approach to the management of software projects, he stigmatizes engineering itself. I respectfully disagree with that point, and notice that nobody I interviewed even mentioned the opposition of software craftsmanship to software engineering.
Producing any non-trivial piece of software is, above all, engineering work irrespective of the selected methodology or management practices.
Still, it’s worth some attention. I have a degree in mathematical engineering and consider myself an engineer. The scientist is someone who solves a direct problem: finding mathematical expressions that explain, and hopefully predict, the behavior of nature. An engineer is anyone who focuses on the inverse problem: given a mathematical model of nature, engineers design systems that solve a problem. Whether this system is mechanical, chemical, biological, electrical, or software, does not affect the definition of engineering. Producing any non-trivial piece of software is, above all, engineering work irrespective of the selected methodology or management practices.
Most criticisms to software engineering are actually objections to principles of management stemming from the the period between the Second Industrial Revolution (~1850) and Fordism (~1920), where the challenge of industry owners was to get mass production from masses of uneducated workers (only primary education was compulsory at this time).
Some regret the pre-industrial era of craftsmen and professional corporations. But should we? Ford’s management principles have been proven inappropriate for more than a half century, and the last decades demonstrated that they are totally wrong and counter-productive to all creative activities.
How many programmers still consider their job as a low-prestige activity and aspire to become ‘consultants’, ‘architects’ or ‘managers’?
The inadequacy of Ford’s management theory is not specific to the software industry. That’s what you would learn in management schools today. Let’s not worry about the past: the management theory has been fixed. However, how many of us developers still believe in this theory? How many programmers still consider their job as a low-prestige activity and aspire to become ‘consultants’, ‘architects’ or ‘managers’?
That’s how we get hordes of bad managers: because we promote people whose only knowledge of management is the ‘wisdom’ inherited from the first decades of the last century.
We can look backward to the pre-industrial era, but we can’t go backward. We as an industry are still facing pretty much the same problem as in the first days of the Second Industrial Revolution. We are still asked to produce a massive amount of software with a high scarcity of skilled workers.
We skilled developers will have to learn to work with less skilled developers. It’s not possible to meet the demand with just the top 5% of us. Furthermore, we skilled developers have the responsibility to make it easier for the less-skilled to produce good software. When we design new languages (consider the step made by Visual Basic, PowerBuilder, Delphi, Java, C# against C++) or new toolkits (PostSharp against plain C#), we don’t only make ourselves more productive; we allow less-skilled developers to produce better software. By lowering the bar on skills, we raise the bar on quality. So sentences like “everything written in Visual Basic is a code smell” are just elitist and irresponsible. If software developers have to serve the society they live in, they have the obligation to make it easier for average developers to produce high-quality software.
If software developers have to serve the society they live in, they have the obligation to make it easier for average developers to produce high-quality software.
There is, however, one difference between the mid-19th century and today: we can now affirm that talent does scale. Social scientists and psychologist have demonstrated that talent is not innate, that the best predictor of high-performance is passion and dedication, because only passion gives you the drive to practice beyond working hours. And here’s where the ideal of software craftsmanship comes back: we can raise the bar of our skills by practicing and by irradiating others with our passion so that they, in turn, get the drive to raise their skills.
Software Craftsmanship vs. Formal Education
There is a growing concern about the mismatch between the skills taught in formal education and what is really required by the software industry. This concern is neither new nor limited by our industry. There has always been a reticence within universities (especially those with a medieval tradition) to the idea that they should produce graduates who are tailored for industry. I tend to agree. Technical skills (languages and tools) are rendered obsolete every 10th year. A masters degree, as I have learned, provides abstract skills, it gives your brains the ability to learn, or design, whatever abstraction you may pick up.
But there is a body of knowledge that is neither tool-specific nor scientific. This knowledge is the sum of our experience, it is what we learned after we spent 10,000 hours building software, and what those who spent these hours cared to share in books. This knowledge is wisdom. Schools seem to teach science, not experience or wisdom.
Yes, there is a body of experience that’s being accumulated by our profession, and we refer to this as “the Craft”. Software craftsmanship says it’s not enough to learn the science, one has also to learn the craft. But is it a good reason to call ourselves craftsmen?
What David Harvey tells us is that, if we call ourselves software craftsmen, people may take it seriously but they will not take note of what craftsmanship means TO US.
We can’t afford to ignore David’s argument. We are going to be treated as what we claim to be.
We have to find a better term to express our values and ideals. What does craftsmanship mean to us? What is our credo? So far, I’ve identified the following points to which I can subscribe:
If what we mean by software craftsmanship is basically an acknowledgement of personal responsibility and what it implies, is software craftsmanship the best term to express our ideal?
- We believe in people above processes. However, we acknowledge the importance of processes and the necessity for the industry to cope with less-skilled developers, and are committed to creating conditions for less-skilled developers to produce better software.
- We believe that our profession owns a body of knowledge distilled from experience which, because it is not genuinely scientific, is currently ignored by formal education. We want to ensure this body of knowledge is transmitted to software developers during their education or their first years of practice.
- We believe that the quality of software depends on the skills of the developers who produce it, therefore we acknowledge the obligation of raising our skills and those of fellow developers. Because only passion can give us the drive to practice and learn above what’s required to survive in our job, we are committed to spread our passion for software.
- We believe that the quality of software we produce directly influences the quality of life, safety and productivity of people or businesses who use it; we consider ourselves, developers, as ultimately responsible for quality, and refuse to deliver software that’s below our standard of quality.
So if what we mean by software craftsmanship is basically an acknowledgement of personal responsibility and what it implies, is software craftsmanship the best term to express our ideal?
We’re not the first profession to care about experience, skills and responsibility. Attorneys and doctors did it before us. They do not differentiate themselves by using medieval words. But they structured their profession to ensure that every new-comer gets the necessary body of experience.
The Problem of Action
The problem with software craftsmanship today is that it is merely a personal attitude; it does not seem to call for any action other than spreading the word and organizing local meetings where developers would practice the craft. This, alone, is not sufficient to raise the profession to the next level.
Look around us. We can get inspired from a lot of institutions. Associations such as ACM or IEEE already provide the structures we may be looking for. Already today, the IEEE Code of Ethics can be the foundation based on which software developers can refuse to work in conditions where they can’t guarantee the quality of their product. So what’s the problem with these associations? Why aren’t we all members? Are they too academic, too far from “the craft”? Perhaps, yes, but it’s something we can change.
Look at associations such as Toastmasters. Their only objective is the deliberate practice, and the diffusion of the art, of public speaking. With membership comes commitment - you’re either a member or not. You can’t just go to every third meeting. Yet still they meet the objective of raising the public speaking bar. They have an international structure; they offer a clear path for new members from any country to become, after years of training, excellent speakers.
Perhaps self-organizing online communities are not enough to bring our profession to the next level. Perhaps we’ll need more commitment. Perhaps we have to forget our “not-invented-here” syndrome and look at existing successful structures around us. But, certainly, we have to act to bring our profession to the next level; blogging and conference speaking is a first step, but it can’t stop there.
Beyond the buzz, beyond the manifesto and the couple of books written on the subject: what does software craftsmanship mean for people who are really building software and how do they turn it into practice?
In a quest for answers, I flew from Prague to London where I attended the very first London Software Craftsmanship Community meeting at SkillsMatter (click to view the recording) and later met up with a number of London .NET User Group members for drinks, then attended the European Software Craftsmanship Conference in Milton Keynes the following day.
I recorded interviews with several software developers over two days in the hopes to add to the already-intense online debate about the subject.
Here’s a preview:
Software craftsmanship is a lifestyle
where I am committed
to high-quality code.
Listen to the interviews. They all sound like an anthem to passion for producing software, care for quality, and responsibility for the future. Software craftsmanship, it seems, is the answer to those for which coding is a passion to those for which it is a livelihood.
Many were attracted to the profession because the demand for programmers was so high. The bar for new hires was set low, and mediocrity reigned as complexity rose and quality fell. Corporate-types addressed the issue by adding “hordes of average programmers” controlled by a pyramid of managers and strict methodologies.
The agile community led the first attack on “the system” and targeted its bureaucracy: methodology does matter, they claimed, but not for the sake of the bureaucracy itself. Methodologies must help to produce software that works, not a pile of documentation that quickly falls into obsolescence.
I am very passionate about what I do,
writing easily maintainable code,
hopefully producing software that will live
for many years.
The attack on bureaucracy is now followed by an attack on mediocrity, and this is software craftsmanship.
Mediocrity is what you get when people do their job from 9 AM to 6 AM and don’t care about the real outcomes of their work. The key word of mediocrity is cover. Degrees, certificates, methodologies, fragmentation of responsibilities, 100% test coverage (any all other dogmas), are there to cover our asses.
I’ve been there too. I almost lost the fire of passion 5 years ago and know many who still feel the flame inside and struggle with this. Software craftsmanship, I believe, is when people say: “no, I don’t want to cover my ass. I know I could and it would be sufficient for me to survive, but I really do care deep inside about what I’m doing, and your external pressures won’t change this”.
Software craftsmanship is something
that every software developer should care about.
for me, software craftsmanship is about producing
high-quality, maintainable code.
The most remarkable thing about software craftsmanship for me is that it states an internal imperative to deliver the best of myself, not because my manager told me so, but perhaps because a man is judged by the quality of his work. What the community tries to express by the word ‘craftsmanship’ is perhaps nothing more than the personal responsibility of the workman in his work.
Caring about the quality
of the code you produce.
This is why the word passion was repeated so many times. What drives us to produce good software is deep inside, and this drive is called passion.
As Geoff Colvin eloquently demonstrated in his book Talent Is Overrated, what really separates word-class performers from everybody else is long and obsessive deliberate practice. Only passion gives you the drive to program during the weekend just to solve a problem.
People caring to do their job
to the best of their ability
to produce a beautiful object.
This journey to the UK was a great moment because, above all, so many passionate – geeks – could meet at the same place. Meeting like-minded people is a formidable source of energy. I wish I could have met them when I felt my passion was being extinguished by bureaucracy.
Passionate developers: thank you so much for sharing your passion! You’re inspiring others to make the right choices. To get out of their comfort zone, and struggle for quality.
A couple of questions emerged from my journey, however:
If software craftsmanship is, above all, a personal attitude: how to turn it into a operational concept? It’s great to meet and energize each other, but what can we do, and how should we structure our communities?
Then, just after I landed back in Prague, David Harvey fired-off this argument: metaphors matter. Are we sure, we professional software developers, we want to compare ourselves, literally, for better or worse, to craftsmen?
That is what I’ll try to answer in Part 2 of my post.
To watch all of the interviews I recorded in their entirety, go to the SharpCrafters Channel.
No time no blog.
It’s been 3 months since the release of PostSharp 2.0 of a lot has happened since then. The release proved very stable, with very few bugs reported. Amazingly enough, I could take real vacation with my family and take a break after the 18 months of intensive work it took to release PostSharp 2.0 and SharpCrafters.
Meanwhile, big customers knocked at the door, sales are already very encouraging, so Roman and me decided to move on and start building a real team. Britt King joined in September and helps building a community around PostSharp. This month we opened a commercial office in United States (more blogging soon), so sales to North America should go much smoother than before.
Our next task is to build a development team, and since PostSharp is so abstract inside, we can afford only the best software craftsmen - and will hire internationally. More soon, but if being paid to work on a product as PostSharp seems the dream job to you, don’t hesitate and drop me a mail :).
Trip to London
Today Britt and I are heading to London. The primary objective of the trip is to attend the European Software Craftsmanship Conference tomorrow, talk with people, meet community leaders, and pick up ideas we can apply to create a community in Prague, or build a company around the values of software craftsmanship. I’ll demonstrate aspect-oriented programming (with PostSharp, of course) with live coding.
Today we’ll attend the first meeting of the London Software Craftsmanship Community (located at Skills Matter’s office) with the same objective of trying to grasp what we really want software craftsmanship to mean, and how to turn an ideal into a working community.
After the formal meeting, we’ll continue the evening in a pub (The Slaughtered Lamb), where folks of the London .NET User Group will join. We’ll discuss and share experience about aspect-oriented programming.
We want to interview a couple of people about software craftsmanship and/or aspect-oriented programming, including Sandro Mancuso, Zi Makki, Ben Hall, Jason Gorman, and Richard Fennel. We’ll try to record the discussions with a camcorder and upload the good minutes online.
Initiating the Discussion
Software craftsmanship has become so fashionable that it’s being misused and abused. I think we face the risk that this term becomes empty if we don’t do some effort to define it. So the question we have to address now is: what does it mean for us to be a software craftsman, and what it does not mean. Here’s a list of questions to which we’ll seek answers during this trip.
- Why should a software developer aspire to be software craftsman?
- What does software craftsmanship mean for you? What it does not mean?
- How are you producing well-crafted software?
- What obstacles prevent you from achieving this ideal of software craftsmanship?
- Personal experience of overcoming challenges?
- Can languages and tools help us to produce well-crafted software
- How can we as a community improve programming languages and tools ?
- How can we as fellow craftsmen raise the bar?
We’ll interview people and upload the recording. But let’s start a larger discussion: what does software craftsmanship mean to you?