But, perhaps surprisingly, many teams have as much trouble getting the automated system up and running as they do in writing the tests in the first place. The problem is their build. They have a system that is sufficient for assembling their software but that isn't ready for the demands of an agile team, demands like continuous integration, unit tests, functional testing, software metrics, etc.

If you have this problem then you should take a look at the Build Engineer Bootcamp that we have scheduled for Minneapolis in April to coordinate with CITCON, the Continuous Integration and Testing Conference. These two events should pair very nicely: attend the bootcamp to learn the basics, then attend CITCON to delve into the state of the art.

Hope to see you there!

Along with a number of bug fixes and enhancements (release notes) there have been a number of significant below the surface changes that should be invisible out of the box but will be a GoodThing:

• Java 5 required to run: this allows us to update the code to more modern Java and to take advantage of the libraries that are part of Java 5 but not Java 1.5. (Of course you can still compile your projects with JDK 1.4.)
• Upgraded Jetty: along with the upgrade we are also exposing the Jetty configuration files to allow more extensions to the default behavior.
• Updated to Servlet API 2.5 and JSP API 2.1
• Specify Log4j config file: there is now a command-line switch (-log4jconfig) to specify the Log4j configuration file. Importantly, this can be either in the .properties format or the .xml format. The .xml format is more verbose (no surprise) but also allows more configuration options. From the Log4j tutorial:

"The properties file does not support some advanced configuration options like Filters, custom ErrorHandlers and a special type of appenders, i.e. AsyncAppender. ErrorHandlers defines how errors in log4j itself are handled, for example badly configured appenders. Filters are more interesting. From the available filters, I think that the level range filter is really missing for property files."

In addition to these change there quite a few little hygiene cleanups that made me happy.

"… there is no secret; there is only the doing of all those little things, each one done correctly, time and again, until excellence in every detail becomes a firmly ingrained habit, an ordinary part of one’s everyday life."

Read more.

Lots of bug fixes, lots of changes to the Dashboard.

New plugins:

• Cincom Smalltalk VisualWorks Store Source Control
• Git Source Control & Bootstrapper
• Http Publisher
• Mercurial Source Control & Bootstrapper
• SVNLabelIncrementer

See detailed release notes here.

For those who haven't heard about it CITCON is the Continuous Integration and Testing CONference, an open spaces (or "unconference") event that attracts an energetic and enthusiastic crowd of CIT practitioners from around the US, Europe and Asia. If you've never been to an open spaces event you can think of it as the best part of a normal conference -- the hallway conversation -- dialed up to 11!

You can read about past CITCONs on the wiki and then register today. But hurry, there are already 120 people registered and only 30 more registrations will be accepted!

If you can't make it to Denver then you might want to plan ahead by registering now for CITCON Melbourne in June or CITCON Amsterdam in October. Or maybe even all three!

I've lost count of the number of times I've heard that. I've even said it myself a few times.

It seemed like it would be pretty easy to do using the dashboard.xml feature of AgitarOne, so I decided to give it a try.

What a great end to the first year of JUnit Factory!

Now I could see it getting tricky if you have multiple build machines, but it seems like that would be pretty easy to handle as well by using different config files for different machines, or something similar. That might violate the DRY principle, so it would be good to think a little more about it. How do others deal with this?

This is particularly exciting because now it can be included in continuous integration setups.

One natural next step would be to set a threshold value so that crap4j would throw an error that would fail the build. I would be curious to hear comments on how people would like that to work.

Anyway, find out how to get the latest version at the blog.

A new version of crap4j has been uploaded to it's new home at http://www.crap4j.org/!

Please check it out and give us your feedback!

Let them eat cake!

at an international gathering, the French-speaking people will have no idea what you are talking about. Even if you say it in French.

In my younger days, before I knew any better, many projects I worked on compiled and published their software manually. You'd type cc and then copy these bits over there and then zip that directory and post it to there. Eventually, we figured out we could write little scripts to automate all the tedious bits and make it less fragile and more repeatable.

One day, I discovered the discipline of daily builds and tools like make and my life got a whole lot better. Make gave us, in Elizabeth's handy phrase "a place to put things".

In Influence: The Psychology of Persuasion, Robert Cialdini describes various techniques for making people do things that, if they were thinking clearly, they would otherwise not do because of lethargy, laziness, or because it would offend their better judgment.

One of those techniques is The Commitment Principle which was used on American POWs to great effect by the Chinese during the Korean War.

Have some extra time on your hands? How about uploading a bunch of the jars to save me some time in the future? :)

Did we succeed in our goal? Check it out and let us know...

(And thanks to the writeup on The Server Side for my title.)

To make this work safely for us we run the tests under a security manager and restrict what the tests can do, so some tests will fail. But if your tests are clean according to Michael Feathers' Set of Unit Testing Rules you'll be just fine.

I have just generated unit tests for some code that would have taken months or years to do manually and I did it in under 30 minutes including registering on your server and waiting for the reply email.

That is truly awesome!"

Getting this kind of feedback is the fun part about having free (as in beer) software up on the web where anyone can try it out. In this case Nick had a great experience with JUnitFactory and let us know with a post to our forum.

The problem is the tyranny of the pending entry. I typically have a queue of dev/testing/ci topics I want to blog and I find it hard to let more personal items jump the queue. In theory I could ignore that I still haven't shared the advice in On Writing Well that sounds like refactoring and dash off a note that Leanne has started he own softgoods workroom... but only in theory. My mind just doesn't seem to work like that.

Today though I read Rands description of Twitter as a yard sale for casual information and was interested. Then I read "I'd prefer to be drinking with y'all, but I'll take what I can get" and knew I had to sign-up.

If you're thinking it's been too long since we've had a beer together maybe you should sign up too?

I might also show off the new crap4j tool that we have been working on lately.

"…AgitarOne is an easy-to-use workgroup product that greatly facilitates the use of unit tests and helps sites get as much benefit as possible from this activity. The result is shorter QA and debugging cycles and much better predictability of the software process. For many sites with large, important Java projects, this solution is attractive and compelling. All such sites are likely to derive value that far exceeds the cost."

Btw, if you're not familiar with the Open Space conference format you might want to read this description. If you're still not sure if this format or event is for you, you might want to see what people have posted about past CITCONs on the web, or read the feedback from Dallas earlier this year.

Those of you familiar with our product would know that we solve some very tough problems ... most of our products work on problems which are defined NP-hard and then solve them to a reasonable and usable level.

So, if you're looking for a challenge and want to be surrounded by equally smart and bright individuals, if you dream algorithms, and if you have a passion to write and test software, then read the posting and apply for either the Senior Software Engineer or the Senior Quality Lead Engineer; other positions are also listed at http://www.agitar.com/company/careers.

If you know someone else that could be a better fit, I would appreciate your forwarding this post to them ... thanks for your help!

I like the informal collegial feel and I'll be interested to see if a community does in fact develop.

If you don't like what you see in the mirror, do you blame the mirror or do you start thinking about spending more time at the gym?

I'm encouraged by the number of people who are interested in unit testing and want to hear our pitch. We've been handing out JUnitFactory business cards like candy -- the ability to generate dashboards is a killer new feature -- and the printed copies of The Way of Testivus are popular as well. (I'm still waiting to see someone put on our karma > dogma t-shirts. Maybe tomorrow..)

I've been mostly busy occupied describing AgitarOne to people but in between I've managed to catch up a bit with Paul Hammant (who is pleased I finally have the include.projects working so he can Branch by Abstraction) and Andy Glover (who is threatening to join us in Belgium). Andy introduced me to prolific traveling speaker Neal Ford, who must enjoy being on the road far more than I do. I got within handshaking distance of ASM author humble committer Eugene Kuleshov but was too busy talking with someone in the booth to do more than exchange greetings.

Looking foward to my next break and the opportunity for some longer conversations...

I also set up a topic proposal for the JavaCamp, unconference that is happening Tuesday and Wednesday nights, on Adding JUnit to the Java Platform.

Here's the blurb for anyone interested:

Many language platforms, like Ruby and Microsoft .NET ship with a unit testing framework as part of the platform. Why not include JUnit in the Java Platform, or at least include it in the JDK? Code quality is a constant sore spot for commercial applications, so it seems like making the tools that contribute to higher quality more widely available will encourage better code. While we're at it, lets put in a code coverage tool as well, so we can see how well we're testing. We already have some profiling and management tools built in, so this seems like a missing piece of the puzzle.

I'd like to discuss this idea, and concerns around improving code quality with developer testing in general.

http://www.artima.com/weblogs/viewpost.jsp?thread=203994

Morgan Conrad asked: "What is Testivus' wisdom concerning the proper percentage of test coverage?"

Here you go Morgan:

Testivus On Test Coverage

Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

...

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

...

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

...

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

Translator’s Introduction

In May 2006, an ill-prepared international expedition to the Himalayas lost its way. After two weeks of wondering around, hungry, thirsty, and smelling like inexperienced expeditioners who got lost for two weeks, they stumbled upon the entrance to an ancient cave.

Once inside, they saw a maze of ancient, and messy, cubicles. Each cubicle had a wooden desk, an ergonomically correct bamboo chair, a Dilbert™ calendar, and a strange computer-like mechanical device. In one corner of the office they found barrels of dark liquid which they later identified as early examples of carbonated and highly caffeinated drink and a ping-pong table. They realized that the cave was an ancient software start-up. The oldest one on record. Older even than Netscape.

Among the many things they discovered inside the cave was a note left by one of the programmers. The expedition’s guide, while not very good at guiding, knew how to read the ancient language and translated the note for them:

We have finished the release ahead of schedule – again. All the tests pass, so we are taking the rest of the week off. We are going sailing. Since it’s a team building exercise, we hope we can get reimbursed for it.

The explorers looked at each other in astonishment. Not only had they discovered the oldest software start-up in history, they had also discovered a team of programmers who, apparently, completed their code ahead of schedule ... on a regular basis!

What was the secret of these ancient programmers?

And what had happened to them?

The expeditioners searched each cubicle for clues and found two mysterious booklets. One of them was called "Learn To Sail In 30 Minutes”, which explained the fate of the programmers. You are holding in your hands a translation of the other booklet: “The Way of Testivus”.

Who wrote this mysterious booklet? What is Testivus? Only Google™ knows for sure.

Is the content of this text responsible for these ancient programmers being able to complete projects ahead of schedule?

We can’t be sure, but we believe that the amazing prowess of these programmers was probably due to a combination of the Testivus philosophy, and the consumption of large amounts of the dark caffeinated liquid found in the cave.

Read the booklet and draw your own conclusions.

Alberto Savoia, April 2007, Mountain View, Ca

CITCON is different from a standard conference in a couple of ways:

• It is free, but scheduled for a Friday night and Saturday. This means the people who attend are the people who are passionate enough about the topic to give up some of their personal time, rather than those people who are able to have their companies pay for it.
• It is an open spaces event. So rather than going from talk to talk and hoping to hear something of interest the attendees build the agenda, with each topic an interactive discussion.

If you've ever attended a conference and left feeling that the best part of the conference was the hallway conversation, then you should understand the appeal of the CITCON format. (At least this is the appeal for me!)

Past CITCON events (Chicago & London) had a fantastic mix of people, including CI and testing tool makers, very experienced authors and consultants, new and experienced Agile practitioners. CITCON Dallas promises more of the same.

Hope to see you there.

Here are a few that I use all the time:

• xml, xpath & xslt
• JSP, EL, JSTL
• Regex

Any more I should know about?

Here are the details:

To Catch a Bug, You Have to Think Like a Bug

2.1.3 A strike is made when a full setup of pins is knocked down with the first delivery in a frame.

Before I move on to the next story, I want to revisit those tests and make sure we have not introduced any regressions.

If I am not mistaken, I have written enough code to pass the acceptance tests for this story.

With enough code, all eyes are shallow.

find out whether something works correctly

The topic comes up about once a year on the TDD mailing list and it just came up again. By an odd coincidence, we just celebrated the completion of a new release of AgitarOne with a trip to Homestead Lanes, so I am all fired up about bowling despite my dismal performance (there was beer involved).

The conference will be following the same Open Spaces (or unconference) format as the 2006 CITCON in Chicago and London. These prior CITCON drew enthusiastic practitioners at all levels of experience, all looking to share what they knew and to learn what they could. We're looking for more of the same in Dallas.

Please help spread the word about CITCON and we look forward to seeing you there!

Paul Julius
Jeffrey Fredrick

"Again from Kuhn:

"The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work."

In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development. "

So if you're interested in the topic I think it would be worth listening. And don't worry, Carey will be the star of the show -- this time I'm just the vendor shill.

On the strong recommendation of Eddie Correia (editor of ST&P) I picked up Thomas Friedman's The World is Flat. That makes it his fault that I didn't sleep on my SFO-LHR flight! I'm not sure everyone would find is as compelling as I did, but for me it could almost be a companion book to my professional memoirs, or at least my memories.

I remember a long conversation the day Roger showed me NCSA Mosaic for the first time. It was the first time I heard the word Netscape (Flattener #2), and then we talked for hours about how the web was going to change everything! A few years later Jayson convinced me that there were some really big ideas there in Open Source (Flattener #4) and we started OpenAvenue, where we hoped to create a collaborative platform for Outsourcing (Flattener #5) and Offshoring (Flattener #6).

And as a parent who has watched the world change I've often felt The Quiet Crisis and wondered if I'm doing the right thing to prepare my children for the future. It is a question that I return to again and again. I'm living in the flat world and I know how to navigate it for myself. But as I hang up from calling my family via Skype on my way to "Asia Pacific's Largest Testing Conference" I don't know what to think about their future.

The main lesson: no one reads anything.

I hope nobody will be disappointed to hear that I'll be speaking entirely in American; my knowledge of German is limited to "ich bein ein Berliner".

Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

For those who aren't aware CITCON is the Continuous Integration and Testing Conference, a free open spaces (or unconference) event on continuous integration and the testing that goes with it.

Given the open spaces format it is impossible to predict what the exact session topics will be but a sampling of the topics (and notes) from the CITCON Chicago event from earlier this year is available on the wiki. Also available are some photos, feedback, links to related blog entries and more... More than enough to be convinced that you should sign up today!

Executive Summary

If the build fails, fix it.

• Agile has crossed the chasm, "everyone doing it" was the word on the street
• Success stories even in very large teams/companies
• Wanted more discussion on how to change culture
• Coding Dojo session was excellent and would make for a good future BayXP meeting
• Data no longer a four letter word! (Refactoring Databases)
• Surprisingly valuable discussion by some Microsofties of their TDD Pair Programming Game (complete with phase transition diagram)
• The Open Spaces part was allocated a horrible space -- think low ceilings and harsh lighting -- and this combined w/the relative neglect compared to previous years led to a feeling of low energy...
• ...except the Getting Things Done session got high marks
• Crushing Fear Under the Iron Heel of Action got high marks with Ron and Chet described as living cartoons (in a good way)

I know there was more but I didn't take notes, so that's all you get, unless some kind soul adds more info in the comments.

Test-Driven Development is often introduced through simple examples, but many developers would rather dive into the deep end. This free webinar is for those people. J. B. Rainsberger, author of "JUnit Recipes," will show you architecture and design strategies to make it easier to "test-drive" J2EE components. You'll learn how to build a J2EE application while following the cardinal rule of Test-Driven Development: Never write a line of production code unless somewhere, a test has failed.

The recorded webinar is up on the Agitar website linked from this page. Registration is required but if you'd rather not register try out bugmenot.com.

We are proud to announce that registration is now open for the next Continuous Integration and Testing Conference, CITCON London 2006 on October 6 & 7. Space is limited to the first 120 registrants and attendance is free. Registration is on-line.

The conference will be following the same Open Spaces (or unconference) format as the very successful Chicago edition back in April 2006. The Chicago CITCON drew an enthusiastic group of practitioners, all looking to share what they knew and to learn what they could.

We would appreciate your help in getting the word out. Please blog/post/email/chat about CITCON London 2006!

We hope to see as many of you there as can make it.

Sincerely,

Paul Julius
Jeffrey Fredrick
Chair-people, CITCON London 2006

But what to do with that failing test?

Is there such a thing as too much feedback?

XP doctrine says that you should stop tracking metrics once they have served their purpose. You should only have 3 or four "Things To Focus On". There's a reason for that.

• replace Xalan with Saxon. this should both increase the speed of the web application and reduce if not eliminate the dreaded OutOfMemoryErrors.
• use an Ant-style launcher instead of setting the classpath in the CC start script or in the manifest.

With these changes we know there will be issues to shake out so we're seeking alpha testers willing to have a go with the latest and greatest and give us feedback on the mailing list.

Are you up for it?

ps: As a side-effect of the switch to Saxon CC versions 2.6 and later will require JRE 1.4 or later (though you can still build projects under 1.3).

It's like what Whitehead said about notation: "By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race."

Outstanding post, Brian. I always wondered what the little star was for in GMail. Now I know. Your post has a little gold one next to it.

To get right to it, here is our basic Agitator / Tinderbox setup courtesy of our Product Manager, Nicole Pauls:

Mocking a singleton is relatively easy.

To begin with, singleton's are all alone in the world; don't be afraid to point this out. Also, most singletons are created, get this, not even in a factory, but merely in a factory method. Finally there is the point that they are little more than dressed-up globals, and IME experience cause more heartache than they're worth. You can point to the many nasty screeds about singletons there are out on the net. All in all, mocking it shouldn't be too hard. A word: if your singleton has unusually large body parts, stoop to insulting that. Sometimes, to be kind, you have to be cruel.

• Updated Xerces and Xalan jars to fix memory leak (CC-426)
• ProjectWrapper: Fix problem where forcing a build while build is running will effectively kill the worker thread leading to all projects queued but not building (CC-431). Patch by John Lewis.

Along with those bug fixes there are a few new plugins:

• ClearCaseBaselinePublisher: New publisher for use with ClearCase UCM (CC-414). Submitted by Kevin Lee.
• LDAPMapper: Email mapper that uses an LDAP lookup to determine user email addresses (CC-413). Submitted by Esa Laine.
• Maven2SnapshotDependency: New sourcecontrol (CC-438). Contributed by Dan Rollo with fixes by Jerome Lacoste.

So what are you waiting for? Go get it...

In math geek terms, specifications are universally quantified statements, ones of the form "for all inputs such that <something> is true of them, <something else> is true of the output." Tests are constant statements, ones with no variables. They look like this: "given input 5, the output is 87."

The main focus is fixtures but it also has some helpers for creating continuous integration scripts. This was all designed around subversion post-commit hooks and there is even a handler for you to run a SimpleXMLRPCServer.

So if you want to adopt developer testing as part of your standard practices make sure you're using Continuous Integration. In the beginning it is the "build successful" messages you'll be looking for, but for the long term you'll be hooked on those times the lamp goes red.

1. Test your own code as well as you can
2. Next time someone checks in a slap-your-forehead bug, show them the test that would have caught the bug if only they had run the tests.
3. Show them how to run the tests themselves

It won't be long until everyone will want to have tests.

Most developers will not make the investment until they have seen proven returns. The management challenge is to find the early adopter with the courage and vision to take that first step.

BTW I often use the Adapter Pattern to wrap a class that seems to need utils until eventually the Adapter grows into a whole new class of its own. I have done this to add utility functions for parsing and xpath querying to org.w3c.Document for example.

Oh, and if you're really really interested in learning more about this topic than can be covered in 5 - 10 minutes (the duration of a short talk) then you might be interested in voting for Paul Dzilenski's Creating an Eclipse IDE Command Line Interface long talk proposal.

Happy voting!

I ran a coverage tool on a project of mine last night and found that almost all the coverage gaps were in boilerplate code. An interface required me to return false in a whole bunch of classes.

The duplication was already bothering me. The duplication plus coverage gaps bothered me enough to extract a common base class. Coverage was back up to almost 100% and I liked the new design better.

Go figure.

What’s that? It’s code that you’re so proud of that you want to take it home and hang it on the refrigerator, right alongside of your children’s drawings.

That suggests that a specification should not be written to a consistent level of precision. Precision is needed only where disputes have already occurred or are likely.

The comments on the entry are enlightening. One comments that this could slow down garbage collection. Another comments that they always make sure that any code in their library that has system resource handles manages the closing of that code. I have used this approach in the past, but it was somewhat ugly.

...one major advantage of TDD is the ability to answer the question "how will I know I am done?". We can aswer that question because we have a test that will fail if we are not done and pass if we are.

I have been consulting for a number of teams that have adopted Agile Methods, including TDD. One common issue I have found is that developers drop the discipline of TDD in the face of schedule pressure. "We don't have time to write tests" I hear them say. Before I comment on the absurdity of this attitude, let me draw the parallel. Can you imagine an accounting department dropping dual entry bookkeeping because they've got to close the books on time? Even before SARBOX such a decision would be such a huge violation of professional ethics as to be unconscionable. No accountant who respected his profession, or himself, would drop the controls in order to make a date.

I want you to build a Hello World application in J2EE. I want you to do the simplest thing that can possibly work.

For the talk about plugin writing, you can download the slides here

Read the original blog entry

I have worked with many testing common organizations where a common pattern is repeated over and over. It goes something like this — we realize there is more manual testing to do than time available, we decide to automate the testing, and we begin working on a test harness. Several weeks later, we have the start of a harness, but it’s barely useful and we still have not written any tests. At this point, we’re behind — so we abandon the harness and revert to manual testing.

Full article [PDF]

I have these rules that I use for unit tests, primarily because I encounter so many teams that start writing end to end tests, call them unit tests, and give up because "testing takes too long". To me, a test is not a unit test if:

1. It talks to a database
2. Communicates across a network
3. Touches the file system
4. You can't run it at the same time as any of your other unit tests.
5. You have to do special things to your environment to run it (like editing configuration files).

Tests that do those things are okay, but to me they aren't unit tests, and they should be segregated from true unit tests.

You can see the replay now if you don't mind registering. If you do, come back in a few days and we'll point you to an unguarded version.

Of course we were incredibly proud winning the Jolt Award by Software Development Magazine - but to be selected for the cover page was even better!

To be sure - the team that has created Agitator and is driving the innovations for the coming releases is (by now significantly) larger than the group on this cover page, but the contributors to Developer Testing were selected to represent the team.

Oh, and Alberto wants to be sure it is mentioned that he is not as small as he appears on the picture - he was sitting on a chair in front of the rest of the group. These vain CTO's!