Sunday, June 22, 2008

What have I been doing on my sabbatical?

Since I stopped working on Feb. 29, 2008 a lot of people have asked what I have been doing so I thought I would write something up. Here is what I have been doing to keep busy.

The objectives I set were to learn more about (1) computer security, (2) Windows Vista/Server 2008 platform, (3) .NET 3.5, specifically WCF and LINQ, (4) concurrency, parallelism, and scalability, (5) agile software development, (6) software design, and (7) advanced debugging.

Books Read

Books Currently Reading

Events Attended

Events Planned

Software I have been playing with

Certification Exams Passed

posted by Kevin Hegg @ 3:59 PM   1 comments

Hacker Halted Conference Summary

I attended the Hacker Halted USA 2008 Conference May 28 - June 3, 2008. My objective in attending this conference was to get a different perspective on cyber security and to evaluate the new Certified Ethical Hacker (CEH) Version 6 curriculum/certification at the request of a friend.

The first three days I attended the CEH course. This is normally a 5-day course. I think it was a mistake to try to jam 5 days of material into 3 days. Too much information was skimmed over or not presented. This was the first presentation of the Version 6 material. I knew that going into the course and expected more issues than were encountered. There were surprisingly few problems with the course material and labs. The instructor, on the other hand, was horrible. He was unfamiliar with the material, read straight from the slides, was not a very good speaker, and injected a lot of personal anecdotes that were laced with inaccuracies. I strongly recommend against taking any course from this instructor, Chuck Swanson. The only saving grace from this experience is that the CEH course material and labs are very good, in my opinion. The course material is over 4,000 pages. After the conference I went through the course and labs in-depth and I learned a lot.

The Hacker Halted conference was held jointly with the Techno Security and AccessData Users' Conferences. In total, there were probably 1,000 people in attendance. Attendees could go to any of the sessions, but I didn't take advantage of that. I attended the Hacker Halted sessions exclusively. I thought the Hacker Halted agenda was good, unfortunately 3 of the best speakers cancelled and their replacements were very underwhelming. The other presentations were good.

The target audience for the three conferences is forensic investigation, computer security, network administration, and law enforcement people. There were very few developers in attendance. I had the opportunity to talk with a lot of people with different backgrounds which is something I was looking forward to. I met some interesting people and had interesting conversations.

I am not sure that I would recommend this conference. It had lots of potential and if it lived up to its potential it would have been a very good conference.

posted by Kevin Hegg @ 2:58 PM   0 comments

Thursday, May 08, 2008

How do I convince my company/client/boss/team/co-worker to do X?

This topic comes up every now and then, but over the last couple of months I have had a lot of conversations with a bunch of folks about "How do I convince my company/client/boss/team/co-worker to do X?" or some variation of that. Since I spend a lot of my professional life trying to influence others and because I am mostly successful in doing so, I sometimes take it for granted that it is just common-sense. People seem to respond positively to my advice so I thought I would share it.

1. Credibility. First and foremost, if you want to influence people you have to be credible. If you are not viewed by others as being credible then it is going to be difficult or impossible to influence others. It doesn't matter whether you believe that you are credible. Credible people are the first ones to admit when they don't know something, so the first lesson is to admit that you can't know everything. If you don't know something then keep your mouth shut. The second lesson is that it can take years to gain credibility and an instant to lose it. Before opening your mouth think about whether there is a great risk of losing credibility and if so then keep your mouth shut.

2. Execution. It is very important that others view you as someone who successfully executes. You can have many flaws, but others are more tolerant of the flaws if you successfully execute. Successful execution helps to build credibility. Also, successful execution is often what grants you entry into a conversation that provides an opportunity to influence others. Don't confuse successful execution with showing up for work and not getting fired. Understanding your role is very important. There are plenty of smart people who lose focus and think they are helping by pointing out the flaws in others. Unless it is your role to do so, and it rarely is, then stay focused on your role. If you don't like your role then change it, but once you are in a role then you need to play the role the best you can.

3. Listening. Often the most influential people are the ones who say the least. If you don't listen then you can't understand others. If you don't understand others then how can you possibly respond to their questions or issues? Even if you know the other person is wrong it is important to let them have their say and it is important for you to listen to what they are saying. Listening can provide you with important information needed for negotiation.

4. Facts. It is very important to distinguish between facts and opinions when trying to influence others. If you are offering an opinion and someone else has another opinion then be tolerant of that opinion. If someone disagrees with your opinion then acknowledge the difference in opinion, but don't fight about it. Healthy debate at the appropriate times is OK, but constant debate about everything can lead to you not being invited into key discussions. When pushing facts (a) make sure your facts are correct, (b) offer supporting data if available, and (c) don't exaggerate. If someone disagrees with facts that you present to them then don't get dragged into a never-ending debate. State the facts, counter the other person's objections once, and end down the conversation. In time, you will often be proven correct.

5. Importance. Don't win the battles, but lose the war. You have a limited opportunity to influence others. You need to understand which battles are worth fighting and which ones aren't. First, if you focus on the most important issues and leave the rest to others then you are going to find yourself being more influential than them. Second, you need to let others participate in the process. You don't want to be viewed as being intolerant, inflexible, or dictatorial. Letting others win the minor things, especially the things that are just opinions of little consequence, can lead to you being more influential. Third, people need to learn and sometimes you learn through making mistakes. Letting people learn through mistakes on the minor things is better than the alternative.

6. Negotiation. Everything is a negotiation. Many non-influential people will convince themselves that they don't have to sell or compromise. They are dead wrong. If you understand that everything is a negotiation then you can come prepared for a negotiation. It has been my experience that most people come into a discussion unprepared for any kind of negotiation. The person who is most prepared is often the most influential.

7. Religion. Avoid religious discussions. It is very difficult to change a zealot's opinions. Zealots often self-destruct and they like to drag people down with them.

8. Permission. Don't ask for permission unless you want to be told no. It is important to understand that people initially react to change negatively. This is human nature. If you want to introduce a new tool or process then just do it. It is better to ask for forgiveness than it is to ask for permission. It is easier to introduce tools or process changes for yourself than it is for an entire team/organization. Become successful by yourself instead of trying to influence the team/organization to change. Over time, if the tool or process makes you significantly more successful than others then it will become apparent. Successful results provide a much stronger negotiating position. Success is also a stronger magnet than failure. People will gravitate towards success.

9. Demeanor. You will be judged by your demeanor. If you come across as lacking confidence or experience then you are going have a more difficult time influencing others. No matter how anxious, angry, depressed, etc. you are you need to hide this from others.

posted by Kevin Hegg @ 2:02 PM   0 comments

Wednesday, May 07, 2008

Edward Tufte, "Presenting Data and Information"

I attended Edward Tufte's "Presenting Data and Information" course this week. This course was on my To-Do list for too long, so I finally decided to attend. It helps that the course was held very close to home and only lasts one day. The course fee includes Tufte's four books: "The Visual Display of Quantitative Information", "Envisioning Information", "Visual Explanations", and "Beautiful Evidence". Overall, it was a good course and I recommend it to others.

The course topics included:
  • fundamental strategies of analytic design
  • evaluating evidence used in presentations
  • statistical data: tables, graphs, and semi-graphics
  • business, scientific, research, and financial presentations
  • complexity and clarity
  • effective presentations: on paper and in person
  • use of PowerPoint, video, overheads, and handouts
  • multi-media, internet, and websites
  • credibility of presentations
  • animation and scientific visualizations
  • design of computer interfaces and manuals

This is a non-technical course that provides valuable guidance to anyone working in a technical job. I found The (Six) Fundamental Principles of Analytical Design in "Beautiful Evidence" to be immediately helpful to some projects that I am working on. Once you read and understand the principles it just makes sense.

posted by Kevin Hegg @ 2:58 AM   0 comments

Monday, April 21, 2008

ALT.NET Seattle Summary

I attended the ALT.NET Seattle event this weekend. I had mixed emotions about attending and didn't have very high expectations. I am fairly new to ALT.NET (3 months). My first couple of weeks on the ALT.NET discussion list just about soured me on the group. There were a bunch of petty, uncivil discussions and there wasn't a lot of useful information coming out of the discussions. Luckily, I was patient and the signal-to-noise ratio has improved recently. The ALT.NET Seattle event greatly exceeded my expectations. There were a lot of intelligent, passionate people who attended. Also, a couple of the ALT.NET leaders spent a lot of effort working to keep everyone civil. I think those efforts made a huge difference. Thanks to the organizers for making this a memorable event.

Friday evening started with individuals proposing topics. The heavy posters on the ALT.NET discussion list and prolific ALT.NET bloggers dominated this activity. That wasn't surprising nor is it a criticism. I just found it interesting to watch. Next, there was a fishbowl conversation on polyglot programming. Fishbowl conversations were new to me, so it was interesting to observe. I think it was the right thing to do because there were some people who would of and could of dominated the conversation. The result is that a lot of people got to say a little bit about polyglot programming, but no one dominated the conversation. The downside is that there wasn't a lot of substance to the conversation. That's OK because it set the mood for the weekend, civil conversations where everyone gets an opportunity to be heard.

The first session that I attended on Saturday was led by John Lam and was about IronRuby and the DLR. He talked a bit about IronRuby progress. They have a ways to go. He mentioned they are using the Rubinius tests as one measure of done-ness and they have passed 89% of the tests. He talked about working with code at the meta and meta-meta level and how quickly things can get complex and hard to maintain.

The second session that I attended on Saturday was led by Dustin Campbell and was about functional programming. Most of the people in the room had very little experience with functional programming so the conversation didn't go very deep. Functional programming conversations very quickly get into how much better suited FP languages are than non-FP languages for handling concurrency. I understand how FP languages have the possibility of handling concurrency well, but I haven't seen a lot of real-world examples to prove it. Concurrent computing is complex. FP languages may help with the complexity, but they aren't going to eliminate it any time soon and they certainly aren't going to push concurrent computing into the hands of junior/intermediate programmers any time soon.

The third session that I attended on Saturday was about ASP.NET MVC. Many of the attendees use ASP.NET MVC. Phil Haack and Brad Abrams from Microsoft attended and fielded a lot of questions. We talked a bit about Microsoft's 5% adoption of MVC comments. The number was just pulled out of someone's butt and Microsoft has no idea how much MVC will be used. I think Microsoft is also very nervous about upsetting their ISV's and large corporate partners. If MVC is widely adopted then it will be very disruptive to the web control vendors. Microsoft is always fearful of incurring the wrath of large corporations who will ask "Why am I building applications with X when you are moving to Y?". The attendees asked Microsoft to stop using the 5% adoption number because it will scare a lot of managers away from adopting MVC. Some attendees also asked Microsoft to make it as easy as possible to leverage open source Javascript libraries and client-side controls. They seemed receptive to the message.

The fourth session that I attended on Saturday was led by Scott Bellware and was about Behavior Driven Development (BDD) / Context Specification. Part of the discussion was about BDD and whether Bellware had hijacked the term to push something else. He admitted that may be the case. He presented an interesting way of testing software against specifications. While I liked some of the things I saw I doubt that what he is proposing will gain any traction. While his ideas were interesting I don't think he presented a strong case for improving anything. His approach was different, not better.

The fifth session that I attended on Saturday was led by Scott Hanselman and was about whether the .NET community innovates or contributes anything back to the open source community. It seems to me that a fair amount of ALT.NET'ers are very bothered by the image that all of the innovation is happening outside of the .NET platform or only in the open source community. I don't understand the insecurity. Why does it matter where innovation happens? I contributed two comments to the conversation. First, I think open source is not as prevalent in the Microsoft space because there is a rich ecosystem of commercial companies whereas in the non-Microsoft space there isn't. Many of these commercial companies provide source code with their products, but they aren't open source companies. Second, while the .NET community didn't invent something, they have a long list of things they greatly improved. I used JUnit vs. NUnit as an example. Scott Hanselman translated my point into "innovation doesn't necessarily equal invention" which accurately summarizes my point. Someone else made the point that much of the innovation claimed by the open source community happened some time in the past. What innovation has there been recently?

I skipped the two Sunday sessions. My son and two of my grandchildren live in Seattle, so I decided to spend the morning with them instead. There were a couple of sessions that looked interesting, but nothing I couldn't live without.

The best part of the event was the socialization. Unlike a conference, user group, or Code Camp where people are expecting to be passively taught, most people came to this event to talk/socialize. I had a number of interesting conversations with people in between sessions, at dinner, and at the bar.

posted by Kevin Hegg @ 2:02 PM   4 comments

Saturday, April 05, 2008

Devscovery April 2008 Conference Summary

I attended the Devscovery Conference last week. Overall, it was a good conference and I recommend attending it in the future. I think it is one of the best value-for-the-money conferences.

Scott Hanselman kicked off the conference with a discussion on ASP.NET 3.5 Extensions. Usually Scott's presentations are very good, but I walked out of this one somewhat disappointed. He started off by asking a couple of "How many of you use X?" questions. I don't remember what he said, but he made some comment that came across to me as the attendees were a bunch of dopes. This completely shut down the audience participation which in turn threw off Scott because he likes to engage the audience. Also, I thought Scott's material was a bit dated.

There really wasn't anything that excited me for the first session so I sat in the "Translating Architectures to Technologies" presentation by Roger Dahlman. This was supposed to be about design patterns and .NET. This presentation was horrible. Dahlman was a very poor speaker, his slides were littered with spelling mistakes, and he came across as not knowing design patterns at all. I got nothing of value from this presentation. At this point I was starting to think that I wasted my money and time attending this conference.

The second session was "C# 3.0" by Jeffrey Richter. Since I feel like I have a pretty good grasp of C# 3.0 I was expecting to maybe get a couple pearls of wisdom out of this presentation. I really liked this presentation. Jeffrey told a nice story about all of the C# 3.0 features that concluded with why all of the new features were necessary to enable LINQ. That was fine, but I knew that already. What I didn't know was that this presentation provided the foundation for the next day's threading presentation.

The third session was "Performance of Every Day Things" by Jeffrey Richter. This was an excellent presentation about how different .NET programming constructs and techniques can affect performance. I already knew most of what he presented, but there were a couple of new things that I learned about measurement that I will use immediately.

On day two I attended the "Day of Threading" presentation by Jeffrey Richter. This was four sessions on threading. I was expecting this presentation to be a refresher for much of what I already knew about threading. I was pleasantly surprised when it wasn't. Jeffrey spent most of the day discussing the Asynchronous Programming Model (APM) that he wrote about in CLR via C#, Chapter 23 and the MSDN Magazine March 2007 and November 2007 issues. One of the issues that he discussed was how difficult the APM was for most developers to use. During the presentation he knocked down the obstacles to using the APM. By leveraging the new features in C# 3.0 he greatly simplified the APM. Throughout the day he ran a number of tests to measure the performance of different threading techniques. His final implementation provided substantially better performance, lower resource utilization, and lower code complexity. He said to expect another MSDN article in the June 2008 timeframe that completes the discussion on APM. He mentioned that the Microsoft Robotics team tried to prevent this article from being published because it provides a vastly superior solution to the Concurrency and Coordination Runtime (CCR). Also, he mentioned a couple of teams in Microsoft that are using APM and are seeing major improvements in scalability. Some of the tests that he ran showed the scalability improvements and they were substantial. I didn't fully appreciate the APM, but I have the religion now. This will play a major role in my development from now on.

The first session on day three was "The Microsoft AJAX Library" by Jeff Prosise. This presentation focused on the client side entirely. He said that he presented the server side of AJAX the previous day. He did a good job presenting the internals of Microsoft's AJAX libraries and discussed how to extend/modify them.

The next three sessions by Jeff Prosise were on Silverlight, "Building Great Applications with Silverlight 1.0", "Building Great Applications with Silverlight 2.0", and "Silverlight Tips, Tricks & Best Practices". All of these presentations were good. I was a little leery about sitting through a presentation on Silverlight 1.0, but Jeff did a good job on focusing on the features that remained in 2.0. Jeff provided lots of sample code that will be helpful in further use of Silverlight.

I was a little disappointed that I couldn't attend any of John Robbins' sessions, but since I did a day of training with him back in December 2007 it wasn't a big deal. I didn't attend any of the non-Wintellect sessions since they seemed to be more focused on the mechanics of basic things. I would have been OK if Wintellect didn't co-host with Infragistics. I think the audiences that both attract are completely different.

posted by Kevin Hegg @ 6:23 AM   0 comments

Monday, March 31, 2008

Throwing out the first pitch at a Major League Baseball game

My 9-year nephew, Charlie Costa, is a die-hard St. Louis Cardinals baseball fan. I have fun talking trash with him because I have been a die-hard Chicago Cubs fan since about his age.

A little over one year ago Charlie was diagnosed with a pretty serious brain tumor. The doctors treated it right away, but in the fall of last year they determined they hadn't gotten all of it. At the beginning of this year he went in for another 6 weeks of treatment. This time the doctors think they got all of it, but only time will tell. This last year has been very tough on Charlie, his mother (my sister), and their family. There have been a lot of trips from Springfield, Illinois to St. Louis for treatment.

The hospital that Charlie has been treated at has an affiliation with the St. Louis Cardinals. When the opportunity for a patient at the hospital to throw out the first pitch came up, Charlie was the first one everyone thought of. There is no bigger fan than him. He will be throwing out the first pitch when the St. Louis Cardinals play the Washington Nationals on April 6. This is such a huge thrill for him and a nice end to a difficult period in his life. So, if you are watching the baseball game and you see a little kid throwing out the first pitch you know the story behind it.

posted by Kevin Hegg @ 9:20 AM   1 comments

Monday, March 24, 2008

High functioning teams

Over the last week on the ALT.NET list there has been a discussion about the "expert" ALT.NET'ers joining forces to form the best IT consulting business. This idea is not a new one. Many have discussed this in other venues and some have acted on it. Recently, Martin Fowler wrote about PreferDesignSkills. This is not a new idea either. What is common between both of these discussions is the focus on the individual. For the first 20 years of my career I fell into the "best individual" camp, however over the last 10 years I have been in the "best team" camp. This change in thought can lead to very different hiring practices and company culture.

When interviewing a candidate I start by evaluating the person on the things they claim to know. If you don't know what you claim to know or are as good as you claim to be in that area then that is grounds for immediate rejection. Next, I evaluate the candidate for capacity and willingness to learn. This is where Fowler and I start to disagree. Fowler values design skills above anything else, as far as I can tell. I take a much broader view. I value candidates with a strong foundation. Design skills are important, but they are just one part of the foundation. Regarding capacity to learn, I am looking for someone who can reason about a new method, technology, process, tool, etc. and develop an informed opinion about if and when to use it. If the candidate only believes in the "one true way" or "one true tool" then they have lost their capacity to learn, at least in that area. Regarding willingness to learn, I am trying to determine how self-motivated the candidate is to learn new things. Next, I evaluate the candidate on their ability to make a team better. Is this candidate willing to play a specific role on the team? Will this candidate help make other team members better? Will this candidate be respectful to other team members? Will this candidate show loyalty to the company, project, and customer? Finally, I try to form an assessment of how much of an investment is required before the candidate is a contributing member of the team.

Getting back to Fowler's design vs. platform skills choice, there are a couple of problems with his conclusions when you look at it from a team point of view. First, what are the skills that are required to round out the team this candidate will be put on? If the team doesn't have all of the skills necessary for the project to succeed then I believe the most important thing is to fill the holes in the team. It is easy to say that you are hiring the person for future and not for the project, but if you put a person on a project that they aren't a good fit for then you haven't done the candidate, company, project team, or customer any favors. Putting any butt in any seat doesn't work, in my opinion. Second, I don't believe that you can make a blanket statement "that a good programmer should be able to pick up a new platform relatively quickly". Some projects require solving hard problems and that may require a deep understanding of the platform. Third, Fowler shows clear bias in design or platform skills. He implies that platform skilled people will never be able to acquire design skills or at least not easily. After a couple of years working in Microsoft Consulting Services I have a very different perspective. I can match his horror stories one-for-one like ripping out 1,000 lines on non-working Spring.NET code and replacing it with 20 lines of .NET platform optimized code or reliance on Rational XDE design-generated code resulted in a sub-optimal .NET solution that required substantial performance tuning or a sub-optimal data access layer that failed to leverage any of the features of the DBMS. My point is not that platform is preferred over design, it's that both play an equally important role in the success of a project.

NOTE: I have nothing against Spring.NET. It is something that I have used successfully, but in this case it was used when it wasn't necessary and it was used incorrectly. The person who wrote this code was a design-focused person who was looking implement IoC and AOP everywhere and into places where it wasn't needed to meet the requirements.

There is a perpetual debate that goes like "1 top-2% developer can outperform 10 bottom-50% developers". You can replace any of the four numbers with whatever you want, but the story is the same. A highly-talented person can outperform a bunch of below-average people. As Craig Andera said at our last ALT.NET meeting, by its very definition we are always going to have many more below-average than highly-talented developers. I've been there and done that. I've been the top developer that outperformed X other developers. So, what good came from it? Certainly, my customers appreciated the efforts, but the team didn't. There are only so many hours in the day that a highly-talented person can work and because there are so few of them it isn't a scalable practice. When I left a project the team wasn't able to continue on the same path or velocity because they didn't get it. When the customer finally realizes the maintenance issues it is too late. Is there something better than this? I think so and have been increasingly working differently over the last 10 years. Instead of stating that I can outperform X developers I ask "How can I make X developers and the team as a whole more productive?". I don't have any numbers to support this claim, but I believe this change in attitude can lead to higher functioning teams. I believe the "outperform" attitude causes you to write off a bunch of people unnecessarily. As in any industry, the IT profession has some useless individuals, but I think the number is a lot less than elitists believe it is.

Back to the original question, can a bunch of experts join forces to form the best IT consulting business? It is certainly possible, but I don't believe it is probable and its certainly harder than forming a corporate structure. I believe the question is too focused on the individual. It takes a lot more than individual effort, no matter how expert, to build the best company. It takes a lot more than individual effort, no matter how expert, to grow beyond a small company. High functioning teams are an essential ingredient to building the best company.

posted by Kevin Hegg @ 10:37 AM   4 comments