What makes a conference talk a good talk?

What makes a conference talk a good talk?

Now; I've spent two days at #oscon in Europe. A commercial event, but mainly about stuff that concerns open source as you would expect. It has been a while since I have been to a conference, so i kind of feel a little bit rusty. I am in no sense of the word a seasoned conference attendee, even if I have had a few talks myself at #JavaZone and some other minor events, participated in quite a few conferences both in Norway, US, and Europe. Short version; I always get excited by people that seems to know what they are talking about and as an added bonus excel in giving presentations.

The funny thing is the delicate balance between being able to deliver a message that is persuasive, concise, composed by recognition points aligned with some fragments of prior knowledge. Being enthusiastic, charismatic, scientific and visible might trump the latter, but it is rarely the case that one or the other is exposed in singularity. I think, being able to convey the essence of something that is important to you is also about wanting you to learn more about the subject or the scientific field. This is the subtle relationships between immediate versus longer term perceived properties of a talk. A talk that might be entertaining at first might not be the one that you appreciated the most in retrospect. For that matter; to evaluate sessions as you go might not be a just way to give feedback when you evaluate sessions at a conference. Note to self, wait a day or two before evaluating talks. Humbleness, being able to refer to real-world cases and observations, good and bad will increase credibility. I think some people, including myself tend to like talks where I may say something like "He/She has experienced the same thing as myself!". Well, it does not bring much new stuff to the table does it?. That someone else feels like you does not make it a scientific fact. However, did you need recognition from someone else to state the same thing that you already knew? The bottom line should be, what is the origin of the problem that you have encountered? Is this solved? If not, what is the alternative?. It is equally important to know what is known, and what is not known. And if the ratio between known and unknown gets to high, it is caught in the sales-rep filter.
I will take some of these note to self points into account when attending my next conference.

Rigid definition of done considered harmful

Most people that has been doing iterative development in general and scrum in particular are probably familiar with the concept of discussing a definition of done. I have more than once been on projects where the concept of done has been defined in one form or another, and where project members have been trying to deliver running parts of a system that is compliant with such a definition. Even more I have witnessed scrum-masters proudly announcing that their definition of done is really done, done, done. The concept of done, done, done will of course be different from appliance to appliance, but it usually ends containing some of these:

• Code checked into SCM
• Code passed QA
• Tests running green in the Continuous build system
• Running part of the code in a test system ready to be accessed by functional experts and product-owners
• Possible discussed and assessed by product-owner before staged to the demonstration environment
• Possibly accompanied by customer driven tests like fitnesse
• Ready to be put into production

My claim goes as follows; forcing your team members to adhere to a definition of done that is to rigid, and using that same definition as a criteria before moving it to the done category on the scrum board (complete in the current iteration), will cause your team to deliver less functionality than they could, and with properties that will make that functionality more difficult to change or even remove. I will try pinpoint why following such a rigid definition along with some indicators on going in the wrong direction.
Just to clarify one thing; for me, writing code with accompanying tests that are checked in and runs green in the CI system is all about the same thing. Make no mistake, I do it and I encourage my team-members, and everybody else for that matter, to do the same.

Team-members are reluctant to pushing functionality out

All those parts that need to be completed to get the "done, done, done" badge might not be necessary or even productive work to deliver the functionality ready for test. Maybe the criteria that says that all functional tests should be supported by a FIT test or some test specified in some BDD-flavor just isn't the way to go if the functionality doesn't lend itself to such a definition easily. Maybe only programmers are going write tests and specifications for that part of the system, in which case JUnit will probably be the best choice for a Java-based system. Not easily being able to comply with the done-criteria will probably cause some developers to go that extra mile to comply even if it is probably not worth the effort for that particular piece of functionality.

Consistency is will of course matter here. Using the same techniques for every bit and piece of the system will make it more consistent. But the strive for consistency will also manifest in supporting test-code or a greater number of test artifacts. These bi-products will have to be maintained and refactored together with everything else, and may actually make it more difficult to change the system later on. It takes experience to know when to put emphasis on consistency over throughput.

Somebody is questioning why we need to work further on something that we have moved off the board

Does this question sound familiar: "I thought you said that this task was done, done, done. We really doesn't have time to take this task back in again". I have heard it quite a few times and although it tends to be accepted, it still surprises me that this is not perceived as the rule, not the exception. If you get all the functionality right most of the time, my claim is that your lead-time to production is probably much longer than it should have been. If you develop build and deploy fast, like in hourly or daily increments, the likelihood of getting it right the first time is probably lower, but the basis for distilling the functional requirement is the running system itself, not some temporary artifact used just for aiding the specification process. Do as much of the specification work as possible in the production code. 

The irony of all this is that it is the people evangelizing on how to eliminate waste that are most prone to push forward a framework to assist in the specification-process where that framework is not part of the code running in the production system. The observant reader may have understood that I am being intentionally vague here, and I have chosen not to prove my point with an example.

It tends to propagate into rigid definitions of other areas of development

The work to be put down to comply to a rigid definition of done to sign off on a user story or a task has the tendency to propagate into all areas in development. I think this is partially caused by the fact that you tend to move the some finalization-criteria out of the common-sense and ad-hoc part of decision making and into an (often) static set of rules. We need some statement on what the rules are, if not for anything else, at least to get some transparency related to the development process so that it may be explained to architects, management and other stakeholders and decision makers.
I believe that the urge to push rigid definitions of compliance rules forward is partially caused by the strive for consistency. The expectation is as follows; if you have rules that govern the development process, in the case the definition of done to move something off the scrum-board, then you will end up having delivering functionality in a consistent and predictable manner. That may be, but what if the functionality delivered is delivered slower than it could be and, and much more hardened in the source-code in terms of difficult to refactor tests and Fit tables.

The same goes for code-qa (pair programming is not always how code comes to light). Way too often this boils down to developers commenting on each-other code that may have been developed another way. Some times it identifies and prevents serious design-flaws, which is great. Developers produce at different levels of quality, use this input in the QA-process as well, it is nothing wrong with checking A's code with a great level of scrutiny while you may browse through B's commit-log in a split second. That's life, learn and educate instead, don't force the same compliance requirements on everyone.

What to do and where to go?

"There is no sense being exact about something if you don´t even know what you´re talking about." (John von Neumann).

It is very important that you observe and take notes of undesired effects of certain rules that your team is using to guide their day-to-day operation. This goes for code and architecture-centric rules as well as for rules that are meant to support the day to day process of harvesting requirements. When undesired effects show up, maybe it is time to remove or adjust the rule accordingly. Maybe this particular web-module wont need the Selenium-harness?, or maybe it does.

All in all it is about delivering functionality in the running system, supported by tests so that you may change code when new knowledge and requirement tells you to. A rumor says that Thomas Edison did not hire employees if the person on the interview salted his/her soup without tasting it. Use your ruleset the same way, don't always strive for consistency when applying your rules, it may lead to code manifesting in a way that makes it harder to implement your functionality fast and with less effort.

Laptop retrospective

Inspired by ma latest post on different cell-phones I have had, I thought I would give it a second go, but now replace cellphones with laptops . I have been using laptops on a regular basis since the 80's because my father had a genuine interests for computers in combination with spreadsheets. I have decided to include these as well since it reflects my overall exposure to these kind of devices, even though they not reflect laptops I have owned, but merely laptops that I have used.

IBM Portable 5155

To call the first laptop a laptop would be to classify the infamous but very effective German Tiger tank of the WW2 light artillery. The IBM Portable 5155 was an awesome computer at the time and the model my father had was equipped with 256Kb of memory. I was at the time barely able to lift the computer; in its heavy-duty plastic case it weighed in at almost 15Kgs!! I had access to this computer from 1985-1987, it was my first experience with a computer apart from using the Commodore 64 at some friends, because I newer actually had one myself.

Power Book 150

The next time I got to use a portable computer on a regular basis after those that my father brought home from work in the late 80's wasn't before 1997 when I had a part time job for SINTEF. The (at the time outdated) laptop was given to me so that I could do some work while doing my military service as a conscript in the Royal Norwegian Airforce. I used the computer to write user manuals and documentation for a system I was working on at the time. I has no connectivity and was offline while doing the work. This was my first experience using a Mac, but I found it quite easy to master.

IBM Thinkpad 380

I got this laptop while I was stationed as a conscript at Kjeller airfield just outside Oslo. I was lucky enough to part of a project programme that was part of a cooperation between Det Norske Veritas, Aerospatiale Missile and Royal Norwegian Airforce. I used it to program a reporting application in Visual Basic for Applications and MS Access. This was the first really nice laptop that I got to work with and the quality and robustness of the Thinkpad series has appealed to me ever since, even though I never got to own one myself. I also used it for a fair amount of gaming, especially Command and Conquer (one of the earlier versions I believe), excellent game BTW. I think that the keyboard on the Thinkpad models have been in a league of their own.

Compaq (unknown)

This was the first laptop that was handed to me for my personal use after I started my first full-time job as a consultant in Sybase, Copenhagen Denmark. The laptop was not new at the time that I got it, but had been used by a consultant that had stopped working there. It had an SVGA screen and a 150MHz CPU. Before started working there I had really been looking forward to the unpacking of my work-laptop, and all I got was this second hand Compaq. To all you guys hiring staff working as consultants. Please give them new equipment when they start working there. This way you will retain loyal staff for a much longer time. I guess however that unpacking a brand new laptop is not much of a big deal now as it was in the 90's.

I haven't been able to retrieve an image of this laptop, and I dond't have have a picture of myself using it so, sorry...

Compaq Armada 7400

Fortunately I got my hand on a much better laptop after complaining about my first laptop for almost a year. This time it was equipped with a 300Mhz cpu and a neater casing. I cannot completely recall but I think it was equipped with 128MB RAM. Decent laptop as far as I remeber, but nothing to be remember as special after I turned it in when I left the company that I was working for at the time, that must have been in 1999.

Dell Latitude (unknown model)

I got my first Dell as my home-office computer while working for Nokia. I did not really need one because I worked so many late hours there that I could not possibly have squeezed in some more office time after I got home from work. It was nothing special with this laptop. I actually didn't use it much as a laptop, it kind of had its home in the docking station at work. It was however good enough to persuade me to get a Dell as my next laptop. I don't remember the exact spec, but I seem to recall that my stationary computer at the time was a 600Mhz, 512Mb something, so I it was along those lines. I really cannot remember how it looked, it was stuck in the docking most of the time. For the same reason I was not able to find a picture.

Dell Inspiron 8100

Equipped with a 1,1GhZ processor, 30GB harddisk, 512MB memory, DVD, WIFI and a 15" 1600X1200 screen this laptop is the most expensive piece of equipment that I have ever bought. Bought in 2001, it was a true kick-ass laptop at the time, and I still have it although I don't use it. Staying at the top of the throne is costly, and you don't stay there for very long. I actually kept this laptop for a record-long period of 3,5 years, so it paid itself in the end. The lesson learned was however to use another long-time strategy; buy cheaper equipment and upgrade more often. This was the first laptop I bought after founding Zenior, also the place where I still work. I could choose whatever laptop I wanted, I guess that is one of the reasons it ended up to be a bit too expensive.

Dell Inspiron 8600

I had been quite happy with my previous Dells so I wouldn't change a winning team. I actually believe that Dell being the only vendor having a decent site allowing for massive customization of the equipment was one of their reasons behind their success. The laptop had a Intel mobile 1,6GHz CPU, 1GB RAM and a 60GB Hdd running at 5400. The display 1600x1200 screen which was good. Apart from the CPU and double up of memory, 2Gb, , it's specifications wasn't that much different from the previous Dell, but the price was about one third. This was to be my last PC, possibly ever.

MacBook Pro

After using PC-based laptops (apart from the brief encounter with a PowerBook in 1997) for more than a decade, I finally decided to give in and get myself a MacBook Pro. I must say, apart for some annoying issues when running Mac-OSX I am very happy with the Mac. My Macbook has a 2,33 GHz CPU, 2Gb RAM and a 15" monitor. I have never regretted to not getting the 17" screen, it is simply too big. I believe that even my graphics-card is the same as in the 17" model so why bother. I got this laptop in 2007, and given my adopted two-year replacement strategy, I am now opting for a new MacBook Pro. I am planning on using that computer as a desktop replacement for my workstation as well. The MacBook is one of the more pleasing products I have ever bought, regardless of category. I am not an Apple-addict, I just find joy working with pleasant technology in an appealing wrapping; the MacBokk fits these attributes nicely.