Brecknock Hall, Southold, NY

I’m in NY this week visiting family and today we got a private tour of Brecknock Hall. It is an amazing building. Brecknock Hall is currently being lovingly renovated by a small group of volunteers. We were fortunate to get a tour because it is not currently open to the public. According to Uncle Bob, our guide, each floor is about 4,000 square feet. There are four floors. As we were being shown around I was struck by several things.

The first thing was the difference in size between the servant’s quarters and the family’s quarters. Four servant’s bedrooms would fit into one of the family’s bedrooms. The cook’s quarters were right off the kitchen and amazingly small. On the right-hand side of the picture you can see what appears to be an addition...that is were the servants lived. Sleeping quarters were on the second floor and there was a recreation room in the basement.

The second thing I found interesting was a very large open space on the second floor at the top of the stairs in the main house. The open area was enormous and was made to improve air circulation. The bedrooms off the open area had levored doors; these doors allowed air to flow into the family bedrooms but still provided privacy.

Some other interesting things: the doors are all different sizes, there are wooden pegs holding many of the support joints in place (cool), there is a safe the size of a small closet, there was an incredible amount of attention to detail with a scroll motif that goes up the main staircase and can also be found on the cornices, every single window in the house has shutters on the inside that fold into the window casing when not in use, there are areas in the attic that look like jail cells with wooden bars (not actually jail cells), there is a small room above the attic where one can get a 360 degree view of the area (Uncle Bob says that birds often fly into the north facing windows), because the boiler made a lot of noise there is actually about 2 inches of dirt in the ceiling over the boiler area, actual window inside the servant’s quarters between a bedroom and the hall (to increase air circulation in that area), the house is solid (thick brick and stone walls).

This house is absolutely amazing. And it is enormous. It really doesn’t look that large from the outside, but once you add a full basement and attic, well...it is. There is still a lot of work to do on it and if you happen to be inclined to contribute to the renovation fund...I’m sure they won’t turn down the money.

The challenge of concurrency

This month’s copy of ACM Queue has got a really amazing interview in it with John Hennessy and David Patterson, authors of the very popular textbook, "Computer Architecture: A Quantitative Approach"

"...From my perspective, parallelism is the biggest challenge since high-level programming languages. It’s the biggest thing in 50 years because industry is betting its future that parallel programming will be useful.

Industry is building parallel hardware, assuming people can
use it. And I think there’s a chance they’ll fail since the software is
not necessarily in place. So this is a gigantic challenge facing the
computer science community. If we miss this opportunity, it’s going to be bad for the industry.

Imagine if processors stop getting faster, which is not impossible. Parallel programming has proven to be a really hard concept. Just because you need a solution doesn’t mean you’re going to find it." - David Patterson

I find this quote extremely interesting because it never occurred to me that the software development community would not rise to the challenge. While I agree that it is a major paradigm shift for many developers, there are pockets of developers who have been building parallel applications for years. I suppose one of the key questions is, can we help our colleagues make the shift?

I agree with Dr. Patterson’s statement that parallel programming is hard. Engineers are required to really know the systems that they are building software on and the tools they are using. As I’ve traveled around giving my presentation on concurrent software development, I’ve found that there are a large number of developers that are not aware of what is really happening in their code. These developers are accustomed to using only the high-level languages they commonly write in and rarely, if ever, dig down into the real bits and bytes that are actually being executed. This lack of low-level knowledge handicaps them when it comes time to track down multi-threading bugs. Remember that threads are a kernel tool and while high-level languages wrap threads to fit their development paradigm, you can’t escape the reality that they are still kernel tools.

"Hey, the world has changed. The La-Z-Boy approach isn’t going to work anymore. You can’t just sit there, waiting for your single processor to get a lot faster and your software to get faster, and then you can add the feature sets. That era is over. If you want things to go faster, you’re going to have to do parallel computing." - David Patterson

There are a lot of folks working on the problem of making concurrent software development easier. By defining technologies and standards: OpenMP, MPI; parallel languages; and new products: Digipede Framework SDK, Intel Threading Analysis Tools, Coverity’s Concurrency Defect Manager.

But at the end of the day the important thing is that people are learning how to think in parallel. Whichever tools they decide to use, right now, isn’t as important as the journey that they are going on. Because if they were paying attention...when they come out the other side they will have a natural and intuitive understanding of how to add concurrency to their applications.

As a developer and an optimist, I'm going to hope that we succeed at this and I'll continue to do my part to help that happen. But we will fail if the engineering community doesn't wake up and realize that times have changed. We have to put a little more thought and effort into adding concurrency to our applications; we have to learn.

Architecture: It's about balance

After my talk for NETDA, someone come up to me with a question about architecture. I emphasize during my talks the importance of simplifying your product’s architecture when you plan to add concurrency. I think a simple architecture is required regardless of the application but is absolutely vital with concurrent applications. The questioner wanted to know to how to convince management that an architectural change is needed. The answer....

Money

An architect straddles the line between business and technology. An architect isn’t out selling the product but she absolutely must understand the impact each technology decision has on potential business. Architectural decisions rarely adhere to technical purity but are a balance between technical purity and business opportunity. There must be a compelling business reason to change an architecture. If there is no business reason, then it is usually more cost effective to leave things alone.

Here are some monetary reasons to change an architecture:

1. To increase architectural flexibility. Increasing architectural flexibility enables engineering to respond faster to new market requirements and even...new markets. Architectural flexibility is vital for startups and small companies because the target market is often moving. It is common for a startup to create a great product idea way before the market is ready for it and as a result have to quickly adjust to a new market. The more flexible the product architecture the faster (and as a result cheaper) the engineering organization will be able to adjust to the new requirements.

Example: Company A (circa 1997) came up with the idea of using user defined patterns to extract data from 3rd party websites. Structuring the unstructured data found on the web. Some people know this as web scraping and this was used early on to do pricing comparisons between vendors. The problem was that Company A was ahead of the game, so they had to branch out into other technology areas. The focus shifted from the web to collecting ANY unstructured data and making it structured. This had a serious impact on the architectural integrity of the product. The company ended up with a tightly coupled architecture (spaghetti code) which made the code prone to bugs, hard to maintain, slow to respond. All of which added up to missed business opportunities because the architecture was not flexible. When I talk about missed business opportunities I’m not saying that they were unable to go after different markets with the product they had. I’m saying that they could have packaged the same code in different ways to create the perception that the products were specifically designed for a given market. Building focused product and marketing efforts that appealed specifically to the target market WITHOUT impacting any of the core product line. This could have been done if the main product line had had a flexible architecture.

2. Improve product quality. There are a lot of good things that come from a good architecture and that includes product quality. I’ll define "quality product" as a software product that works as expected, is stable, easy to enhance, and easy to maintain. At the root of any product is the product’s architecture and poor architectural decisions will result in poor product quality.

Example: Company B (circa 1996) had decided several years prior to my arrival, that they needed to build a new casino video game system. It was a market that they were already in, so they knew what the system had to do. They choose an embedded system; built the operating system, payout system, configuration system, and games. Everything done in-house. The problem was that they were two years late with no end in sight because the system was so buggy. Part of the problem was that the system was built by hardware guys with a lot of hardware experience and very little software experience. Fortunately they knew they were in trouble and hired a software gal...me. Their problems were all fixed by a simple change to the architecture. Seven months after I started working with them, they were good to go. The product was approved by the Gaming Commission and the company was successfully sold. Architects who are inexperienced or technical purists will often try to redesign an entire architecture. That is rarely cost effective. A good architect balances the business needs with the technology needs to create a compromise that lets both sides win.

3. Improve productivity. As I said it’s about money. So if by making an architectural change you can help your company either save money or make money by increasing productivity you can usually sell that to management. This is usually the type of thing that happens for internal projects. But productivity gains can also occur by enabling unit testing, increasing the ability to add enhancements, speeding up maintenance, automating help file generation, etc...

I’m sure that there are other reasons to change architectures. Changing tools, enabling other OSs, etc... but at the end of the day; if you don’t have a compelling business reason to make the change (which is usually directly tied to some revenue opportunities) leave the architecture alone.

GNoTECon take aways...

Monday’s GNoTECon was very informative. I learned a few things, got validation on a few others, and met some very interesting people.

Root and Branch
Mary Trigiani asked a very important question during one of the panel discussions that was basically along the lines of, "Is the rise in technical evangelism a result of a failure of marketing?" This is an important question because the answer is vital to help understand how technical evangelism will mature. At its root the question is asking, "Why was technical evangelism invented?" Technical or secular evangelism was invented to fill some needs and it has grown because these needs are common. But what are the needs? Has marketing gotten too passive? Has it lost touch with the markets it’s trying to reach? Do technical products need to be marketed differently? Are people tuning out marketing messages?

Knowing why technical evangelism was created and has grown is also important to understanding how to better reach our prospective customers. All the presenters emphasized the importance of getting in front of people and telling your story. But flying people all over the country is expensive. When an entrepreneur sits down to write her first business plan does she have to factor in the expense of evangelism? Has this become a requirement for startup success?

Startup Techniques
There was a lot of talk about trust, honesty, integrity, and transparency. An evangelist’s reputation is vital and the evangelist must strive for transparency so that when he says something people will believe it and not dismiss it as a sales pitch. In a startup there is a fine line between being an evangelist and being a sales person. If you cross that line then you lose credibility and as a result your company loses.

I had inherently suspected this and it was very interesting to hear it emphasized so much. Here are some low cost techniques we use to try and spread the message:

- Microsoft Groups: The Digipede Network has a very powerful SDK and so that opens our products up to developers. I watch the developer groups and forums for opportunities to mention our product. I try very hard to be respectful when I post a response by not making it a sales pitch but rather to offer technical assistance and point out options. I actually will mention Alchemi sometimes or threading if that is an option. I also answer posts that are not directly relevant to Digipede. I do this because it’s the right thing to do and I think that that is one of the root elements to evangelism...helping people be successful.

- Blogs: With my blog and on other people’s blogs I try to add to the conversation. Which is what blogging is all about. Over half of the Digipede team is blogging because we believe that blogs are a very effective communication tool. What is hard about blogging as an evangelist is again that fine line between adding value and selling. I’ve seen people push their products without adding anything else to the conversation and I know that when I see something like that, I don’t like it. I love the idea of blogging because it’s the geeky honesty thing at work, out where everyone can see it. I’ve written before that I think engineers are required to have a thick streak of honesty because of the nature of our jobs. And because I am pushing a product that has an SDK component, you will find programming stuff on my blog. Even programming samples that are not directly tied to Digipede. The reason for this is again...helping people.

- White Papers: Yes, I’ve written a couple white papers for Digipede. These just take time to write, but creation and distribution is basically free. Stick them on the web site and make them accessible.

- Videos: Video creation has gotten extremely easy and cheap. While our videos are not the highest quality available, YouTube and other video sites have lowered the quality bar and made this okay. Dan has become the face of Digipede and he tries to make the videos informative and educational. More "here’s what’s in it for you" and no "here’s why you need to buy this".

- Talk to Everyone: We talk to anyone and everyone. That’s how Dan got on DotNetRocks!. He told the guys what the Digipede Network can do, they thought it was cool, and now you can listen to Dan and Carl talk about grid computing. Dan just asked. What’s the worst anyone will say? If they say "No" you’re no worse off than you were before.

- Give Presentations: I will talk to any group that is within a 4 hour drive of Oakland, CA. I will fly to any city where I can get a $250 or less round-trip ticket. Just get me 20 people to show up to hear what I have to say. But I don’t just talk about grid computing and Digipede. I talk about concurrent software development. I did this because the first person I approached about presenting was Oliver Nguyen, President of the Bay .NET User Group. Oliver was very helpful and he pointed out that .NET user groups don’t want a sales pitch. They want to leave the presentation with something that they can use right away. So, I talk about concurrent software development, why it’s important, design considerations, and two concurrency tools: threads and grid objects.

- Piggy Back on Partners: The Digipede team works hard to form solid, positive relationships with our partners. Especially our large partners who have significantly more resources than we do. This really paid off for Supercomputing 2006 because we were invited to hang-out in HP’s booth. And for the SIA Management Technology conference we were in the Microsoft booth AND in the Microsoft break room. The Microsoft break room was very cool because it was where Microsoft, HP and Digipede products where being demonstrated working together by a Microsoft employee. Hardware: HP Proliant Servers; OS: Microsoft’s Windows Computer Cluster Server 2003; Software to pull it all together and demo: Digipede. This was great. John blogs a lot about partnering.

- Webcasts: We also have taken advantage of doing webcasts with MSDN. These webcasts are free, on a Microsoft site, and searchable. The fact that the webcasts are hosted by Microsoft adds validity to the presentations. I see these webcasts as being evangelistic, we also do monthly webcasts but those are presented to folks who have identified themselves as prospects.

- Make it Easy: We provide a free Digipede Network Developer’s Edition which is a fully functional Digipede Network, the only limitation is that this version only supports two compute nodes. But this is enough for people to see how easy it is to set up and use, and to see a performance improvement. There are plenty of code samples and complete documentation. Providing the Developer Edition has helped us get free reviews. Mike Gunderloy of Larkware was kind enough to do an unsolicited review. This was awesome.

- Community: We have a community board that is one way we communicate with users. What’s great about using a forum format is that if we’re not here, the board is. So if someone runs into a problem they can search to see if someone else has run into the same issue or post to get help. I did like the idea from the SAP evangelist about using a point system to encourage more participation, but we haven’t implemented anything like that...yet.

These are all low cost techniques that we have been using to spread the message that, "Yes Virginia, you can do grid computing on Windows and it’s really easy." You can even grid-enable Microsoft Excel.

Customer Evangelists Rock!
Customer evangelists are the most credible and enthusiastic messengers. I wish I had a hundred. What more can I say? Except that I wish it was easy to identify who has the potential to become a customer evangelist. As was pointed out by many of the presenters, these folks are often not the ones you were targeting.

Things I Learned
Most of what I learned on Monday validated what we are already doing. But there were some other great ideas and they came from Guy’s presentation.

- Go with your strengths. Guy pointed out that a product may be built for a specific market or to solve a specific problem, but if users come up with something else...support that something else.

- People see things through the lense of what they already know. Wow. Great point. Obvious point, but only after it was stated.

Conclusion
This was a great event and I’m glad I went. I think evangelism has become an important part of the product life-cycle. Yes, I said product life-cycle. Because evangelists are also educators and remember that a product is far more than the software or hardware. It’s all the other stuff that makes it easy for customers to find value. If you’re interested in learning more about Technical Evangelism then I recommend you join gnote. It’s very easy and it’s free.

Technorati tags: Digipede, Grid Computing, Distributed, Excel, Technical Evangelism , Evangelism, gnote, GNoTECon

.NET Developer Association...Come On Down!

Welcome .NET Developer Association folks. As you look at this blog to help you decide whether to attend my talk next week, let me tell you that I was a senior server engineer in one of my past lives. This is not a marketing talk. In the threading section of my talk we will look at C# code, assembler, and discuss common mistakes that threading newbies make. This section is a deep dive. The software development community must embrace concurrent software development to take advantage of the new multi-core machines. It is up to you to be prepared for this by becoming knowledgeable about concurrent software development principles and tools. The two tools that I will discuss are threads and grid objects. I will also discuss concurrent design and process ideas as well. This is a big subject but an important one. So I hope to see many of you there!

Out and About: December 2006, USA

Well, as usual we’re busy here. Even sandwiched in between holidays we have a lot going on.

December 4th
Dan and I’ll will be attending the first Global Network of Technology Evangelists (GNOTE) event. If you haven’t already registered, get to it. We aren’t presenting but some notables are and some large companies are contributing speakers. This event should prove interesting and educational.

December 6th
John and Nathan are going to be in NYC attending a Microsoft HPC event for the financial services market. Not only is John going to present some very cool ways to use the Digipede Network with the newest Microsoft products, one of our clients is also a featured speaker. So if you’re in the NYC area...don’t miss this one.

December 11th
I’ll be in Redmond, WA in the evening presenting to the .NET Developers Association my talk on Concurrent Software Development. Be sure to print this page so that you can get in. Make sure that you read the Security Checkpoint section so that you won’t have any problems.

I also have a late flight out on Tuesday so if you’re interested in setting up a meeting let me know. I’ll be happy to give demos on Tuesday featuring just the Digipede Network.

December 26th – 29th
Well, I’ll be home for Christmas and for me and my family that means Long Island. We’re staying for a week so if you are on Long Island and would like to setup up a meeting, send me an email. We’re staying in Southold so I really don’t want to go all the way into NYC, but I am willing to meet on the island.

Happy Holidays...