No Fluff Just Stuff Twin Cities Spring 2009 Review

The Spring 2009 Twin Cities No Fluff conference was last weekend. I enjoyed the weekend seeing old friends and learning new things.

I have to give out some gratitude to Jay Zimmerman for putting the conference together and running the show. Every conference I've gone to has appeared to run flawlessly.

My experience in the sessions was excellent. I spent the first day listening to Ted Neward's talks about Java Platform Security and what we might see in Java 7.

For Java 7 it looks like there will definitely be significant performance improvements. Chiefly, the introduction of the G1 garbage collector seams to be generating the most buzz.

Java Platform Security is something that have been largely unaware of. Neward did a good job explaining some of the Java security APIs and how we can implement them in our applications today to make our applications less vulnerable to malicious attacks. One thing that stuck out as a good practice is to run a comprehensive set of tests on a Java application and see what permissions are needed and then modify the security policy to accommodate only those necessary actions.

I commented that the security session was a little bit dry. One of my friends commented that if I said it was dry it must have been...well what do people think of me?

Neil Ford gave his keynote "On the lam from the furniture police." It's a great talk. That was actually the second time I've heard it and it was just as much fun the second time as the first.

Day 2: Stuart Halloway's Programming Clojure talk left me very hungry to give Clojure a spin. I like what I see in Clojure over Scala. Both languages have me interested though. The things I really like about functional languages is the simplicity in which they express functions. Functional programs take very little space to express function. The example Halloway gave reduced a 10+ line method from Apache Commons into a single line of Clojure.

One question that came up in the functional language discussions is: when are the functional languages going to become the killer app? The need for functional programming seems to revolve around concurrent programming and multi-core CPUs. My thoughts are this: right now 2-4 core systems are common. By using only a single core we're realizing roughly half to a quarter of our systems' potential. I think that when 16, 32, and 64 core systems are more common, then we're only going to realize 1/16, 1/32, or 1/64 of our system's potential. Something amazing is going to realize that potential and at that point I think the bandwagon will begin to fill.

The next session that I found to be very informative was Ken Sipe's Java Memory, Performance and the Garbage Collector. Great content and great delivery. Ken Sipe is becoming one of my favorite speakers on the tour. Java memory management is something that I admittedly have treated with the cargo cult mentality of setting the -Xmx to 1Gb and hoping that the Out of Memory errors go away. I had never heard of tools like visualgc, but I think it will be in my tool box of Java memory tools. It's a very cool JVM memory monitoring tool. I think that a lot of the mystery behind the garbage collector will not be so mysterious anymore.

I attended Ken Sipe's Hacking-The Dark Arts. Hacking/security is an interest of mine so some of his content was not new to me. It was a good refresher on some of the more common security vulnerabilities--SQL injection and cross site scripting.

On day 3 I enjoyed Mathhew McCullough's Git talk. I've heard great things about Git and I'm even using it as a source repository at home. I'm really not using it effectively though. I think that I will be much more effective with it now.

Neil Ford's Domain Specific Languages and Regular Expression talks were very informative to me. I think that both of them gave valuable content.

I concluded the conference with David Hussman's talk on Lean agile development. If there's a speaker who knows how to end a conference on a nice tranquil note it's David Hussman. I always leave his talks feeling far more relaxed than anybody else.

The takeaway that I'm getting is what I've suspected in the agile space. It's getting crowded with people who don't understand what they are doing. I don't know how I feel about it. On one hand, people are improving the way they work and realizing tremendous value from adopting some of the agile practices. On the other hand, people are doing 'agile' things that don't make any sense to them and poisoning agility within their organizations.

Another thing that occurred to me is none of the new agile practices are all that new. They're only new to the space of software development.

I've been mulling over what will be the next thing in software development practices. I'm trying to think beyond agility. I don't know what it is, but I think something new is needed. I think it will need to involve more of an organization than just the business users and development.

I'm still digesting the conference experience as a whole. I enjoy NFJS, but I'm beginning to wonder which conference will be the first one that I take a pass on. I didn't decide to go to this one until I saw the schedule and decided that I could find a valuable session for each time slot. I don't know if that will be the case this fall. It will be hard to determine whether there is enough new content to justify going.

One thing I'd like to see are more sessions with deeper content. I'd like to see more 2 part or even all day sessions that really have a deep explanation of topics. The 90 minute expository sessions are good for some things, but I feel like I'm at a point where I want to come out of the conference really understanding the content. There were too many sessions where the content was abbreviated for time.

I found the conference to be valuable. I thought that all of the sessions that I attended were worth attending.

No Fluff This Weekend

It's hard to believe that it's time for the Spring Twin Cities No Fluff Just Stuff Conference this weekend.

I've been looking at the schedule trying to decide what sessions I plan to attend. I think I'll follow Ted Neward's sessions on Friday. On Saturday I think I will attend Neil Ford and Ken Sipe's sessions. I know better than to even think about what I want to attend on Sunday--I will probably get interested in something else and attend that instead. But as of now I think I'll probably attend one of Nate Schutta's sessions and one of David Hussman's.

This will be an interesting conference. I would be surprised if it sold out in this economy though. There are rumors that many of the area employers are cutting/eliminating their training budgets. I can respect the decision, but I still think that people are paying a tremendous opportunity cost by not attending.

This will be my fourth No Fluff conference. Each conference I've attended has significantly helped me become much better at what I do. I'm willing to invest a full weekend of my life to attend the conference because I believe the value is outstanding.

My favorite cooking show

At No Fluff Just Stuff Ted Neward opined that he hates cooking shows. Ted hates cooking shows because the format of just about ever American cooking show is to show the host throwing ingredients into a pot, mixing them around and then they go to put them into the oven and then BA...might get myself in trouble using that word, KABOO...nope that one's for toilets, ALACAZAM!!! magically a delicious finished meal emerges from the magic oven.

Through the magic of BBC programming on American Public Television I grew up watching Keith Floyd on his show, Floyd on Food. Floyd's format is different. His show follows him as he prepares  and enjoys the dishes. Floyd also cooks with wine, some for the food and some for himself. You just don't see television chefs putting themselves three sheets to the wind during the show anymore. I think that's a bit of a shame.

Floyd on Food, as I watched it was all about delicious food and enjoying a meal and a bottle of wine. His guests were some of the most untelegenic people I'd seen, but they were knowledgeable and genuine. They also had a lot of fun presenting the show.

I went ahead and embedded all of the online clips of Keith Floyd cooking that I could find. I really wish that more resources ware available.  The first and last clips are the only clips from the Floyd on Food that I grew up watching.

The more recent episodes have more polish and better production values, but they also ditch the magic oven format that annoys Neward, Perhaps watching Keith Floyd will change his opinion of food porn. I think we, as a people should really do more to make the world more enjoyable for people like Ted Neward. Just kidding, I'm glad there are people like him who have opinions and are not afraid to share them.

As you may have noticed in the earlier episodes, the people aren't exactly the types of people that you'd see on television today. They're, kind of ugly and plain looking. It's almost as if they chose their guests based on the content of what they have to offer and not because they look good for the camera. I miss that, aside from the Sunday morning political news shows, you really don't see that on TV. 

Even though the people don't look all that good that food looks great, even on a horrible picture.

To Err is Human, to Accept That to Err is Human is Agile

Agility is approaching, if not already in buzzword land. A buzzword is a word that is overused or used without regard to its meaning. The result of the abuse of the term is that the word ceases to have meaning.

The value of the term agile is waning, but the ideas behind agility are still relevant. Even if the word agile is losing its meaning, it doesn't hurt to give defining it a shot. 

I was challenged to think what it means to be agile this weekend at No Fluff Just Stuff. David Hussman made a statement that agility isn't prescriptive. David said there isn't a simple list of steps that a group can take to transform themselves into an agile group. He even went on to suggest, and I'm paraphrasing here, that if you are an organization that is looking to find a simple list of bullet points that will make you agile, that you probably will be very challenged to be agile.

I agree with Hussman that agility isn't a template that a group can follow to magically become Toyota. A development organization can look at a set of 'agile' practices and be no better off than if one of those practices were to follow a waterfall model. It isn't about what you do or how you do it.

Agility, and this is my definition, is accepting that mistakes will be made. The mistakes are then drivers that present an opportunity to change the way that a team works to accomplish their goals. 

To me that's it. Take what you're doing and regularly question and evaluate how it's working and be willing to try alternatives. If something isn't working, make a change and see if it works better.

Iterations are conducive to agility because they embed a mechanism for reevaluation into the process. Having an iteration though doesn't make the process agile if the process isn't adaptable.

The biggest problem I see in the agile space is there are many organizations out there that are clearly not agile, but they want to be. They want to be agile and they look at organizations that they see as agile. They look at the delta between their practices and the agile company's practices and create a roadmap to get to the agility. It's a plan for failure--and that could be a good thing, but it probably won't.

The process of roadmapping agility into a set of static actions is ironically the opposite of being agile. Agility is adaptability, it's recognizing change and it's also recognizing necessary change. A big driver of change is failure, but failure is an element of agility that people shy away from.

As humans, I think we shun failure. We hate it. We hate to lose and we hate to fail. Fear of failure drives many of us to go through extraordinary efforts to perceive ourselves and to be perceived as successful. 

Instead of fearing failure I believe that we should embrace it. Failure can be a wonderful learning experience. The key to embracing failure is to make the failures uncostly and educational. Small failures can drive changes that add big value. 

Being agile is recognizing, embracing, and accepting small failures and using them as a waypoint for improvement. Celebrate your failures and use them to your advantage and you will be agile.

Security and Usability are at odds with each other?

At No Fluff Just Stuff in the Security Birds of a Feather session, Ken Sipe and Ted Neward both made interesting statements. 

Ken said that a secured logging system is the most important element to a security system. His reason for saying that is, even if damage is done, you'll want to know what happened. 

Ted made a good point that the vulnerabilities are likely to be through social engineering rather than trying to crack any difficult systems. That only makes sense that someone who is interested in defeating a systems is going to attack its weakest points. People have lots of weaknesses.

Ken mentioned an anecdote of a group of penetration testers who left a few USB flash memory sticks that were loaded with root kits and other goodies in the parking lot of their customer. Employees of the customer found the flash memory and couldn't resist the urge to stick them in the computers. It was game over after that.

Probably the most interesting, to me, statement made was one to the effect that for a system to be usable some degree of security must be compromised and vice versa.

The statement was in response to the single sign on trend.

That is to say that at the extremes a very usable system is insecure and a very secure system is unusable.

I agree that some measures that are performed in the name of security completely shred usability and that some things that are performed in the name of usability hurt security.

I don't see a single axis security/usability continuum. I truly believe that secure systems can be built that are secure. I also feel that I am not qualified to design these systems, but these are the recommendations that my unqualified self would suggest:

Stop relying on passwords so much. Passwords provide a single point of failure should one password become compromised. In one environment I worked, that was supposedly very secure, the security people required everyone to change each of their numerous passwords every sixty days. Say if one were to have ten accounts, each with its own password, keeping track of those passwords is a bit of a chore. Memory fails people and they will rely on other means. Some will use something like password safe. But there are some who will rely on the old paper backup. Good thing that nobody thinks to look under the keyboard.

Ted Neward touched on one good solution for usability challenges with authentication and that's multi factor authentication. I like multi factor, because it dramatically increases the difficulty of breaking a system without necessarily sacrificing usability, instead of one challenge, there are multiple. The factors usually fall into three categories, what you know(passwords, questions), who you are(biometrics), and what you have(objects).

This is how an ATM works, you have a card and you rely on a fairly weak password There are 10,000 available combinations for a 4 digit PIN. We don't worry about the relatively weak PIN because we're pretty good at keeping track of our ATM cards. Falling prey to social engineering schemes with our cards are far more likely than someone taking an ATM card and guessing the PIN.

I'd really like to see more multi factor security systems in place. If one of the factors in the system is an object, like an RSA token, then adding a relatively easily guessable second factor, for example why not provide a factor of selecting a picture of familiar objects out of a lineup of ten, twenty, one hundred other pictures? Pictures are easy for people to remember. The pass picture lineup may only provide a namespace of 100, but it only adds(multiplies) to the strength of the other factors.

People have mixed opinions about biometrics. I'd hate to think that by amputating a part of my body, someone could defeat a security system. Some of these systems can be defeated in some clever ways.

Multi factor is more about the combined strength of systems instead of requiring a single system and cranking its strength up to 11 and cranking the usability down to zilch.

I think we really do need to question why security systems are typically so unuseable and whether they really need to sacrifice usability for security.

No Java Unit Test Tool For Thread Safety Testing--I'm taking notes from Ted Neward's Concurrency NFJS online

Ted Neward mentioned that he is not aware of a unit testing tool for thread safety. I think that there should be one.

Ted recommends reading Release It by Michael Nygard.

Ted says never ever ever catch throwable. It can really hose up a threaded app.

JVM guarantees 32 bit atomicity. Longs and doubles are 64 bit, they need to be synchronized.

Threads don't switch on code lines. Threads switch on operation lines.

Threads are permitted to keep a local copy of field values if field not declared volatile.

Ted recommends Java Concurrency In Practice by Brian Goetz.

Field visibility is irrelevant to thread safety.

Two myths of the Java language: it is expensive to create objects and it is expensive to synchronize code.

Out of Training Budget? WTF?!!!?!

Good training, or investing in the skills of one's employees is one of the best investments a software development organization can make. Next to getting excellent people, training those people should be a no brainer. If you are reading this and you have the ability to allocate a budget for training your people, allocate a generous budget. Make it easy for people to use that money to receive training. Your people will thank you. 

By providing training, you're adding a benefit to the position that will attract the types of people you want. People who are interested in what they do and interested in investing the time to learing how to do it better. 

I will confess that my professional opinion of people is affected adversely by those who refuse training. I understand that people have obligations outside of work that doesn't allow them to easily receive training. Nothing is free in the world though. Everyone must sacrifice something to train. If you only get to spend so much time with your kids, I really don't fault someone for choosing their kids over their careers. 

There are opportunity costs with the time it takes to get training. I'm more apt to think less of people who choose rewatching a Battlestar Galactica marathon over training. It's not that they are bad people, their choices of priorities are just telling to me about where their profession stands.

In short, training is important to me.

It's confession time. One of the driving factors behind my decision to leave my last job was the way the company handled, or failed to handle, training. I don't want to dwell on the past, but I recently learned that they are continuing their ways.

The company in question is financially very sound. They are seated comfortably north of 150 on the Fortune 500. The company is flush with resources, but they are disciplined in managing expenses, no they're stingy. One would be hard pressed to accuse the company of wasting money on snap decisions. I would say that they are guilty of wasting money through their reluctance to spend money. Below is an example of my experience.

The department that I used to work in emphasized training as an initiative for the year. They kind of had to because many of their software developers didn't keep up with what's going on outside of the company. Skill set stagnation could easily be attributed to shaky engineering and ultimately system downtime and other defects. 

As part of the initiative, all software engineers in my department were required to spend at least 20 hours in training for the year. Here's the catch, they don't count attending user group meetings, which are free, as training. They also don't have enough room in their training budget to accommodate 20 hours of training. 

My own experience was around No Fluff Just Stuff. In my opinion, NFJS is an outstanding value. For around $700-$1000 they offer 11 90-minute presentations over the course of a 3 day weekend. 

The speakers are excellent. Every time I've gone to a NFJS I've learned things that have made me better at my job. It's also a great networking experience. They arrange the conference so people have the opportunity to network. I personally payed for the conference that I will attend this weekend.

Back to the company. They royally messed up in the Spring conference with me. The managers in  my department, and our director, and our VP were all on board with sending as many engineers as possible to NFJS. 

I knew that attendance is limited and that they offer early bird discounts. About eight weeks before the conference I was tasked with getting a list of people in two different cities who are interested in attending. I did and submitted it. 

The training was quickly approved through our department, though we heard nothing about it. The deadline for the early bird discount approached. People came to me asking about the conference. I, in turn, asked the managers. They believed that the arrangements had been made. Since I hadn't heard anything I emailed Jay Zimmerman, the conference organizer to see if everything was cool. Jay, promptly replied to let me know that only the people from the first conference had been registered.

I explained the situation to the managers around me, they tried to escalate the situation, but our contact in finance refused to reply to any of our emails or answer the phone when we called. She also refused the emails and calls of our director. She finally did reply to all of the people who wanted to attend the conference telling them that, as punishment, they would need to write a report on everything that they learned and have it ready the following Monday for the CIO. She ended her communication by offering them an out, do you still want to go?

The communication seemed petty and intended to discourage people from getting training. More accurately, it was intended to discourage people from costing the company about $18,000 to get over twenty people training.

For less than the price of sending a few people to Java One, we were going to be able to send more than twenty people to quality training.

They did register us for the second conference. They also mistakenly registered one of the people in both events. They wasted about $5000 by not just registering people in one group early.

I believe that had I not persisted and insisted that the registration be done that it never would have. It got worse, the company stiffed No Fluff with the bill for a while. Or they never disclosed that they were going to pay net 30 from the time of the last event. So I got a really alarming, yet polite, email from the organizers.

I made two replies, one reply was to all explaining who the proper contact is. The second reply was directly to the person in finance who failed to acknowledge our emails or phone calls and a few people within my department. This is the same person in finance who told us that we'd need to write a book report. I asked her to deal with this issue. I also stated that I was uncomfortable having my name associated with financial delinquency.

Her reply, which copied a few additional directors and VPs, was that if I didn't like having financial delinquency associated with my name that I should deal with these people myself. That was the straw that broke the camel's back for me.

There was no apology for her unacceptable behavior. Nobody thanked any of the attendees for spending their weekends getting training. No, it was a big up yours, where's your book report!

Fast forward to my exit interviews I made certain to candidly explain that the events I just explained heavily contributed to my decision to leave the company. There were other things, but to me, the way they handled training for me personally was utterly unacceptable.

My hope in explaining those experiences was that they would accommodate training requests more seriously and give their software engineers training needs more consideration.

I recently learned that they dropped the ball on the fall conference and didn't register a few people who wanted to attend. They were told that they'd be able to go, however they learned that the company didn't have enough room in the training budget to send them. This was communicated after the last discount price had expired. 

What the hell is wrong with them as a company? On one hand they tell their people that they want them to get training and that the company wants to invest in their skill sets. On the other hand, when the employees try to take them up on the offer, they're met with resistance, hostility, and incompetence. What are people to think?

The message that I received is that they are disingenuous about valuing their employees and their careers. How frustrating is it to have a manager tell you that you need to do something, but they won't support it? They have no problem giving the employees more work than can be done, but they aren't willing to give them training or tools. They lie. 

There are only so many times when you can lie to people before your words cease to have any meaning and the credibility of management ceases to exist.

I'm very happy with my own decision to leave after those events, I wouldn't be surprised if others chose to leave after they experience similar events.