Bill Blogs in C# -- Business

Bill Blogs in C# -- Business

Created: 2/20/2013 5:23:06 PM

In this post, I'll drill a bit into the final of the 3 areas SRT is investing in for 2013: Continuous Client Experience.

Users are now expecting that their experience, their work, and their data follows them from one device to the next. It's not enough to have a presence on mobile, web, and desktop. It's important that users have a seamless experience as they move from one device to the next.

One high profile example is Netflix. I can start a movie on my laptop. When I get home, I can switch to my Roku and have the movie pick up in exactly the same location. My picks are the same on my phone as on the living room device. We just expect that experience to move from device to device.

OneNote provides similar behavior as a productivity application. My notes automatically sync in the cloud. As I move from machine to machine, or to my phone, all my data just follows. The newest version of OneNote doesn’t even have a “save” command. My work just moves to the cloud on a regular basis.

All the applications we are now writing for business users demand the same kind of synchronization. It's driving several design decisions.

We're putting data in the cloud, where it's accessible from multiple devices. We're putting more effort into how we synchronize data. We're putting thought into server side data crunching and client side rendering. We're designing applications that have more and more of their algorithms in the cloud. That lets us develop more and more of the functionality for a single server platform. Each client has a smaller footprint and less device specific code. That lowers the cost of creating a great experience on each device. Finally, we're investing in making great offline experiences that synchronize data when the device notifies applications that a network is available.

Put all these areas together, and we believe we're well positioned for an exciting 2013. There are major shifts underway in our industry, and we intend to stay at the forefront.

Created: 2/11/2013 7:06:03 PM

At SRT, we continuously examine the overall technology landscape and make decisions on where to invest more time, what should stay the same, and what should be getting less investment. The change is actually quite fluid. We are always looking at what can help our customers achieve their goals, and what technologies seem to be getting less emphasis in the future.

But, the beginning of the year seems to be the right time to make a statement for the coming year. Here goes:

We’re seeing three areas that deserve big investments this year:  Mobile, Single Page Web Applications, and the seamless integration of user experiences.

Let’s start with mobile: We’ve been building mobile applications for years, and demand continues to grow. There is obvious growth for iPhones, iPads, Android Phones, and Droid tablets. Windows Phone 8 and Windows 8 tablets are adding strong competition as well. There are a number of questions relating to how much market share each of these platforms will enjoy. But there is no question that the overall market for mobile software is growing, and growing quickly.

But mobile is only half (or one third) of the story.

Our customers demand that users access applications from their main computer as well as from their mobile device.  Modern web applications, termed “Single Page Applications” behave more and more like desktop applications everyday. Facebook and Gmail are the two most popular examples. These web applications provide an almost native experience in the browser.

This gets to the final and encompassing strategy decision:  Applications we’re building now must be available to users on any device, at any time. Data must be available on the web, on mobile devices, or on the desktop/laptop. The best apps can move seamlessly from device to device.  That requires building applications that are part mobile, part web, part cloud, and always available from anywhere.

We’ve positioned ourselves to build those applications.  We’ve got strengths on mobile platforms, web platforms, cloud platforms, and most importantly, building applications that span those different environments.

In my next few posts, I’ll go into more detail on each of these three topics: why they are important, and how to learn more about each of these topics. In the meantime, what do you think? Are these where you’re investing? Do these ideas represent the kinds of applications you want to use? Leave comments.

Created: 2/11/2013 7:06:03 PM

At SRT, we continuously examine the overall technology landscape and make decisions on where to invest more time, what should stay the same, and what should be getting less investment. The change is actually quite fluid. We are always looking at what can help our customers achieve their goals, and what technologies seem to be getting less emphasis in the future.

But, the beginning of the year seems to be the right time to make a statement for the coming year. Here goes:

We’re seeing three areas that deserve big investments this year:  Mobile, Single Page Web Applications, and the seamless integration of user experiences.

Let’s start with mobile: We’ve been building mobile applications for years, and demand continues to grow. There is obvious growth for iPhones, iPads, Android Phones, and Droid tablets. Windows Phone 8 and Windows 8 tablets are adding strong competition as well. There are a number of questions relating to how much market share each of these platforms will enjoy. But there is no question that the overall market for mobile software is growing, and growing quickly.

But mobile is only half (or one third) of the story.

Our customers demand that users access applications from their main computer as well as from their mobile device.  Modern web applications, termed “Single Page Applications” behave more and more like desktop applications everyday. Facebook and Gmail are the two most popular examples. These web applications provide an almost native experience in the browser.

This gets to the final and encompassing strategy decision:  Applications we’re building now must be available to users on any device, at any time. Data must be available on the web, on mobile devices, or on the desktop/laptop. The best apps can move seamlessly from device to device.  That requires building applications that are part mobile, part web, part cloud, and always available from anywhere.

We’ve positioned ourselves to build those applications.  We’ve got strengths on mobile platforms, web platforms, cloud platforms, and most importantly, building applications that span those different environments.

In my next few posts, I’ll go into more detail on each of these three topics: why they are important, and how to learn more about each of these topics. In the meantime, what do you think? Are these where you’re investing? Do these ideas represent the kinds of applications you want to use? Leave comments.

Created: 1/25/2013 4:35:35 PM

I try not to write posts that are simply links to other posts, but I had to make an exception for this.  I was quite happy to see Scott Meyer's post on writing an effective effective book earlier this week. I received an earlier version of this advice almost a decade ago when I first worked on the proposal and outline for Effective C#. That advice, and all of Scott's additional advice and counsel made all the books I've written for the Effective series better. His guidance and advice are a key reason why the Effective Series books are so successful, and so well-received. The the authors in the series receive this advice, and receive constant feedback on the content, the form, the advice, and the style that goes into an Effective book.

The advice I got from Scott helped in many areas beyond writing that book. It has helped me become better at writing in general. I'm also better at explaining difficult concepts when I'm speaking to developers, or in meetings with other technical leaders. I remember several review comments from Scott on my first manuscript that started, “I don’t know C# very well, but this doesn’t make sense to me. Will your readers understand this?” It made me rework several explanations for greater clarity, and to be more complete.

If you're thinking of writing a book, you must read this post. It contains many nuggets of information that will help you reach your audience. You'll explain your points more clearly, and you'll justify your arguments much better. Your writing will actually accomplish its purpose.

Even if you don't plan to write a book, you should read this advice. If you work in technology, and you ever explain difficult concepts to coworkers, managers, customers, or others, this information is very useful. You'll be more effective at work, and your advice and counsel will be taken more often.

If you've enjoyed the books I've written for the Effective Series, this post gives you a glimpse at Scott's advice to make those books as useful as they've been. It’s invaluable advice. Read it. It will help you as much as it helped me.

Created: 12/14/2012 6:36:23 PM
We are excited to announce public classes for developers launching in January of 2013. Twice a month, we'll host .NET developer training classes for professional developers that want to grow their skills. Our curriculum is based on the wealth of material we've created to help .NET developers learn more about the C# language and environment. As readers of my blog, you're probably familiar with my books, videos and articles. But it's not just me. Patrick Steele has a regular column in Visual Studio Magazine. Many of our .NET developers have spoken at conferences and created content that we'll use in our classes. The format, the delivery, and the content are tailored for busy professional developers.  Each month, we'll conduct two afternoon sessions. One will be focused on a recent release to help developers learn the latest tools and techniques.  The second will be focused on mainstream releases to help developers become more proficient with the tools they are already using. Each session includes discussion and demonstrations. Most importantly, half the time will be spent on labs that provide guided experience on the topics being covered. We'll repeat sessions if there is enough interest. All the classes will be hosted by the experienced conference speakers that have been providing developers with great content for years. We're excited about this launch. It augments but does not replace our core focus: creating great software for our customers. Our area, like many locations, is experiencing a shortage of developers in certain areas, such as C# and .NET. That talent gap is slowing economic growth here. As Dianne and I have gotten more involved in the regional business community, we began looking for what we could do to help. The obvious choice is to help new developers in the community grow their skills. In fact, we’ve already hosted private classes for many of our customers. This launch enables us to reach a wider audience. Longtime readers of any of the blogs on our site know that SRT Solutions has a commitment to continued learning. We know that this industry moves fast, and we have to continue learning to stay relevant and move ahead. All our developers spend time learning new techniques and creating content. It helps us created create great applications for our customers. It also positions us to help other developers in our region.  Our goal for this new program is to train the developers that our growing regional companies need to grow. It's our way of closing the talent gap. You can learn more here. You can signup for the first two sessions here, and here. Finally, this effort doesn't stop with .NET.  We're also hard at work finalizing the curriculum for alternative languages on the JVM, HTML5/JS, mobile Development, and cloud based development. Those will be going live in the next couple months.
Created: 10/23/2012 5:56:58 PM

I often find myself in conversations with customers and prospective customers regarding how we build software. How do we build software? What’s our process? How are we tracking tasks? What documentation do we create?

With some customers, we get a lot of pushback on the lean, fast process we use. According to these people, we don’t generate enough documentation. We don’t do enough manual testing. We start coding too soon. I’ve observed an interesting quality to these conversations:  The person (or people) questioning our process is most familiar and has extensive experience developing software at least 20 years ago. Equally importantly, they no longer develop software, either professionally or casually.

Like all conversations, everyone brings their own perspective to the conversation.  A couple decades ago, our tools were different. That meant a different process was better. These customers are bringing that natural bias to the conversations, and it comes out in their questions. Knowing where that bias starts makes it easier to explain the differences in a positive way.

Picking up that new codebase today

Let’s start with how today’s tools support and enable our current process. Suppose I was handed a large codebase we’ve created, and I needed to make some changes.  The first thing I would do is to get that project from source control, build it, and run the automated tests. That would give me the following information:  I’d expect all the tests to pass. If they didn’t, we’d have a serious problem. I’d expect that the tests cover a strong cross-section of the codebase. (I wouldn’t expect that we’d have 100% coverage, but I’d expect something in the high 70s, at a minimum).

Already, I’ve got a level of confidence. If I start making changes to this codebase, without doing any deeper investigation, I would expect that the automated tests would alert me if I’d made any change that introduced a regression bug.

Read that sentence again, because it’s a huge confidence builder for a new developer on any project: As a developer, I will know if I’ve broken anything even before I check the code into source control.

Next, I’d string trying to find the area of the code I need to modify. I’d use the search function in my IDE to find classes, methods, or modules with names that make sense. I’d pay special attention to tests the exercise the feature I’m going to work on. I’d read the test code. I’d use the “go to definition” feature of my IDE to find the code being exercised. I’d learn about the sections of code I’d need to modify.

Once I felt a bit comfortable, I’d start writing new tests to express the changes I would make. I’d leverage intellisense to see what the capabilities of the types I’m using are. I’d expect some reasonable method names to help me understand what’s already implemented.

Overall, I’d feel reasonably comfortable making changes and adding features within a day. I’d probably be quicker if the codebase was smaller. 

Many open source developers learn a new project the same way. They look, they learn about the project using the source, they dive in.

Picking up a new codebase in years past

But it wasn’t always like this. Decades ago, we didn’t have powerful IDEs. In those dark ages, we started by reading voluminous documents. Those documents gave developers the roadmap and that important first handle into a large codebase. Next, a developer would read and digest detailed specs on the modules to be modified. Then, and only then, would someone make the first tentative steps into modifying the code.

Unit tests weren’t standard practice yet. Developers approaching a new codebase wouldn’t have that security and that safety of knowing that mistakes would be caught early. Any mistakes will escape to a QA department. Even worse, any mistake might even make it into production or distribution.

The common languages we used were very different. C was by far the most common language. The other main players were PASCAL and FORTRAN. Today’s common idioms for encapsulation were rare. You had to be careful about modifying global variables. Global variables weren’t a code smell. They were necessary. That introduced more risk into each change. That increased risk meant more process.

The extra process was necessary because the tools weren’t able to support greater speed. The costs of mistakes were high; we didn’t have a high probability of catching problems before customers did. Worse, we couldn’t give new developers the confidence to move quickly, especially on an unfamiliar codebase.

That extra process also carried real overhead. At my first job, we had librarians. They were responsible for helping developers find the necessary documents or code for a particular problem. Yes, their entire job was managing the documents we created. That overhead may sound like waste today, but it wasn’t. These people were instrumental in helping developers be productive.

We also had a much larger QA and test department than you would expect for a similar sized organization today. That’s because so much of the testing was done by hand. And, of course, the test organization meticulously followed test plan documents. There was also the science of sampling those test plans for sniff tests and regression tests (and rotating the sample so that over time every test was executed).

Understand Upper Level Management

The upper level managers I talk with had similar first job experiences to mine. One big difference is that they often left the ranks of main line developers to become managers many years ago. When they first hear about the lightweight process we use, they don’t see it as leveraging the tools. Instead, they see it as being sloppy. I have to frame that discussion in terms of moving fast and leveraging modern tools if I want to make any headway.

I can’t talk about the lack of test plans; I have to talk about the overwhelming number of automated tests.

I can’t talk about lack of documentation; I have to talk about documentation in the form of an Open Source project’s wiki, and IDE tools to browse, search, and learn about a codebase. Most importantly, I have to separate the act of creating a design (thinking and collaborating) from the act of writing a design document.

I can’t talk about lack of a firm plan; I have to talk about measuring velocity and responsiveness (even to change).

Most importantly, I have to explain in very clear terms how the artifacts we needed to create in the past are not necessary because the tools enable us to do more, do it faster, and become familiar with a project much faster.

I’m not saying that the people I’m referring to are dinosaurs, out of touch, or anything of the kind. I’m writing this to point out that they, like all of us, bring our own biases to every conversation. These same biases color our decisions. If you want to move these managers away from those processes they remember as necessary, you must explain why they are no longer necessary.

Remember this anecdote when you find yourself trying to change a process that’s no longer bringing value:

A newlywed couple was working on a roast for dinner. The young bride cut the ends off the roast and put them into a second smaller pan. The young husband had never prepared a roast this way, so he asked why. The bride said she didn’t know why, but it’s what her mother always did. The called the bride’s mother and asked why. She said she didn’t know either, but it was what her mother had always done. So the young couple called the bride’s grandmother. The wise grandmother laughed and laughed. When she finally stopped laughing, she said “I can’t believe you’re still doing that. I only cut the ends off the roast because when your grandpa and I were young we didn’t have a roasting pan big enough for a roast that would feed all of us.”

Don’t continue to use a process that’s no longer necessary with modern tools. Equally important, remember that those processes once had a purpose, and you need to explain why modern tools render them obsolete.

Created: 10/2/2012 7:11:14 PM

Thanks again to Carl and Richard for inviting me to come along to Omaha to join the awesome community in Omaha. I continue to believe that the strongest development communities are in the middle of the country. There are always strong crowds, engaged people, and good old mid-western friendliness. I’d love to see more of the big name conferences try locations in the Midwest.  There’s a huge untapped community of developers that would attend these conferences if not for the extra large travel expenses.  And, these developers are so energized that they are starting their own conferences in many of these locations.

Carl, Richard and I had a great discussion that is available here on .NET Rocks. We discussed how the software we create continues to change the world around us. My talk before the recording was around the concept that as developers our career is about changing the world and creating new possibilities. Software changes the way we do everything:

  • Delivering Health care has been radically changed by software.
  • Listening to music is completely different now that we buy music as files, not discs.
  • Watching TV and Video has been transformed by software.
  • Travel, retail, education.
  • Everything we is changed by software.

Our jobs are helping our customers create and adopt new workflows and new ways of leveraging software to make things better.

I talked about looking for different ideas, and being aware that often the best ideas are dismissed. As an example, I mentioned Steve Jobs fight to get the iPod released. His board fought him on that, saying that it had no market. The interview with Steve Jobs and Bill Gates that I reference is here. It’s long (2 hours or more), but it’s worth your time to listen to these giants of our industry discuss how they navigated long careers starting with home built computers on to the modern devices we now use.

The final point was why WinRT needs iTunes (or something like it). So many people use iTunes and and iPod (of some flavor) for their music source. Personally, I find much better value from ZunePass (now XBox live music). However, with the demise of the zune player device, those files aren’t portable. Music you download using your subscription is DRMed and can only be played on a linked device. I can’t plug my Windows 8 slate into my car. I can’t use it while I work out, or while I’m walking the dog. I need to get my music on an extremely portable device.

Today, that means iTunes and and iPod.

If I can’t do that on a WinRT device, I need another computer to manage my music library. That means I’m more likely to buy an Intel Windows 8 device, even if it’s only to manage my music. If I had a way to get my Zune music on a portable device (besides my phone), I’m set.

Created: 9/29/2012 7:27:37 PM

We released our first Windows Store app earlier this week:  A calculator app that supports multiple skins. 

We’re concentrating on adding the art and user experience to make a better experience for our customers.  The first skin is a steampunk skin.  It’s   novel look at a simple application:

SteampunkLandscape                                       SteampunkPortrait                               SteampunkSnap  

 

 

The Second skin is a kids calculator skin. Note that this skin has fewer functions than the steampunk skin. we wanted to make an app you’d be happy to let small children use to check their homework:

 

KidsLandscape                                   KidsPortrait                                       KidsSnapped

 

 

We also added history and sharing features. If you use the calculator in snap mode, or portrait mode, the screen has 5 lines of display instead of 1. Also, you can share from this app, putting all the calculation history as text in an email message, or a document.

We’re working on other skins and more functions.  Please use the comments to let me know what you’d want to see.

Created: 5/16/2012 1:10:14 PM

I really enjoy creating software. I’m thrilled to be part of this industry, and able to create useful apps for people our customers. But yet, if we want to remain productive and engaged throughout our careers, we need to actively exercise other parts of our brain from time to time.

It’s too easy for many of us to fall into that trap of doing the familiar, working the same way, choosing the comfortable path. That kind be stifling. You do the same things the same way, and it becomes habit.

If you want to stretch, you need to open yourself to new ideas, make your brain do different things, and grow.

That’s why we did a workshop this past winter with The Improv Effect. It was an exhausting afternoon of fun. Our entire team ran a number of different exercises. Throughout the afternoon, everyone was laughing, thinking, and trying to produce the best improv sessions we could. it was fun because the exercises are designed to apply humor to your daily activities. you look at challenges from a different perspective when you’re trying to make them humorous. It was exhausting because you use very different parts of your brain than you do when creating code. You’re reacting to your partners in Improv. You’re listening very carefully. You’re doing the first thing that comes to mind. You’re going to make mistakes and fail. A lot. And then, you need to recover.

Because of all that, maybe software development should be more like Improv. We should handle change. We should handle updates. We  should handle mistakes. If you’re tasked with making innovative applications, stretching the boundaries, and implementing new ideas, maybe you need to treat your brain the same way: Stretch it. Try new things. Innovate in different areas.

I encourage you to try totally new disciplines. We found Improv a great way to expand our minds. I encourage you to do the same. And, if Improv isn’t your thing, look for other opportunities to grow your brain in other areas.

Created: 5/10/2012 7:06:30 PM

Public Service Announcement: I interrupt our regularly scheduled technology content for a discussion of government policy.  If that’s of no interest, just skip this post. Regular tech posts will resume shortly.

I spent the early part of this week in Washington, D.C.  in meetings with legislative and executive staff on issues relating to the software industry. I’m glad you’re still with me. What our government does (or doesn’t do) affects us. We should pay attention.

ACT Online wrote about the event here.  Morgan summarized the focus of the event quite well. Rather than repeat the main concepts, I’ll discuss my own experience from the perspective of a developer and business owner in Michigan.

The software industry is one of the main bright spots in our economy. It’s continuing to grow. The jobs the software industry creates are high-paying jobs. I went to Washington to help ensure that our policy makers understand that they have both a positive and a negative impact on our industry. The software industry is still young, and we are constantly creating new applications and new technology ideas that open up new areas of innovation.  This industry has been especially instrumental in Michigan’s recovery. New businesses, like ours, have grown over the past 10 years. Larger companies are making new investments in software. The renewed investment in Detroit is almost completely due to software companies.  Public policy affects the environment for new businesses, influences society and education, and creates the regulations that govern our commercial interactions.

Overall, our message is that government has an important role to play by allocating public resources, like spectrum. It also has an important role to play in regulation. We want consumers to feel safe when they interact with software companies, whether those companies are large corporations or small one person startups. Finally, and most importantly, we know that government has an important role to play in creating a society where people have the skills and talent to help the software industry keep growing.

That last item is the most important, in my mind. We had a fantastic meeting Monday morning with Danny Weitzner, President Obama’s Deputy Chief Technology Officer for Internet Policy. (As an aside, when 30 tech people have a meeting at the White House, they all get some impressive bragging rights on FourSquare). One of my key messages there involved education and building the talented workforce we need. There is a lot of discussion around STEM fields, and ensuring that more young people become interested in these fields. Much of that discussion misses the mark.  There seems to be an emphasis on training for a specific job (Java programmer, iOS programmer) rather than careers (software application development). Our software programs are created by teams with diverse skills: artists, designers, User Experience experts, developers and more. The game industry includes script writers, musicians and engineers. While we need people with specific skills, we need creative people that can come up with new ideas and implement them even more. Changes to our education system must address math and science. More than that, it must create life-long learners that have the breadth of knowledge and the creative skills to create the next Instagram, Facebook, Google or Microsoft.  When we hire people, we ask questions that are outside the realm of simple coding questions.  We want to know if you can think about problems, come up with new ideas, make new products that people haven’t even thought about wanting. I was really excited to see Mr. Weitzner latch onto that concern.

Overall, it was a great trip, and a great way to take my perspective on our industry to our governmental leaders.

Created: 3/20/2012 7:52:23 PM

Over the weekend, I read this post “6 ways Microsoft is Killing the Traditional Desktop in Windows 8”.  Like many headline hungry opinion writers, there’s a large share of hyperbole in this article.  The headline also implies an incorrect motive.  I won’t speculate on whether or not Microsoft wants to kill the traditional desktop. However, I think I’m on safe ground when I say Microsoft wants the Windows 8 Metro desktop to succeed.  If you market and sell applications on Windows, you should rephrase each of his 6 ways as motivation for getting your applications on the Metro platform:

 

Your Users Start in Metro

Do you want your application front and center in your users’ cognitive space? Do you want them starting and running your application everyday?  Once Windows 8 comes out, that means running as a Metro App. If you want your application visible on a daily basis, using live tiles to update status, and enticing customers to launch your app, your application must be in the Metro start menu.

Modern Apps win

You have a choice of environments in Windows 8:  “Modern” (meaning Metro) and “Desktop”, meaning, well, not modern.  If you’re competitors are more modern than you are, they will win.

Touch First wins

The Modern interface is a touch first experience. Chris Hoffman is not the first author to mention the phenomena of wanting to use touch on his windows 7 machine after using Metro. It really is compelling. Once your users have a touch-first experience, they will gravitate toward those applications that work for them in the touch environment. If your application is the competitor with a solid touch experience, you can successfully take marketshare from competitors that have not made a touch investment.

Desktop applications are not first-class apps

The Desktop is a Metro app. That means desktop apps do not show up as individual apps in the task bar, or in task switching. They have limited features for sharing, standard metro menus, and more.

Metro apps will be more fully integrated into the Windows 8 experience than any legacy desktop applications.

Metro Apps have greater market reach

Windows 8 runs on Intel x86 and i64 processors. It also runs on ARM processors, used on tablet devices where battery life is a key driver.  Traditional desktop applications will not install on ARM devices running Windows 8 (exceptions may be made for Office, Windows Explorer, and a few other Microsoft applications.  If you want to reach the greatest market, you must create Metro apps.

The Windows App Store sells Metro Apps

The Windows App store makes it easy to install apps, try them, rate them, and purchase enhanced versions or add ons. It makes it easier for customers to try new applications safely, and purchase those apps they like the best. The App Store keeps track of the apps a user has purchased, and automatically installs any updates and bug fixes. That lowers your support costs: users will be automatically upgraded to the latest released version.

OF course, those business features are only available for Metro apps. If you’re trying to sell legacy desktop mode apps, you must still manage this entire process yourself. Once again, Metro apps incur lower costs, and gain new benefits from the ecosystem.

Some closing remarks

Windows 8 is a big change from Windows 7.  When it is released, existing Windows 7 apps will look as dated as Windows 3.1 applications looked when Windows 95 released. That change drastically modified the marketplace at the time. Those companies that were ready to ride the wave of Windows 95 started a very impressive growth curve. Their competitors that bet against change slowly faded from relevance. Regardless of the platform, the software industry has proven time and again that betting against the latest upcoming release is a bad idea. Stay close enough to the leading edge to stay relevant.

Created: 2/7/2012 4:16:33 PM
We experienced a great example of the efficiency of self-organizing teams last Friday. We’ve been in the same offices for several years now, and like many tech people we’ve started to accumulate aging tech equipment, and other stuff just lying around. That’s in addition to all the normal stuff that any business accumulates. It was time to reorganize the physical space. We allocated last Friday afternoon to finding a place for everything and putting everything in its place. There was very little pre-planning. Dianne Marsh and I made two specific recommendations: We were moving the bookcases into one office, and mounting a 42” TV / monitor on the wall in the library. Everything else was organized by the team. Our developers, our office manager, our sales and operations staff all pitched in. Everyone looked at where they could best help, took on tasks, and got things done. By the end of the day, all the clutter was stored in closets (neatly). All the equipment was in one space. The TV was on the wall, the bookcases were moved. The books are on the bookcases, totally organized. No single person was in charge of the process. Everyone made decisions, and then communicated those decisions to others.

What can we learn from this to apply to other activities?

If you want to experience the satisfaction and the efficiency of self-organizing teams, I think there are a few lessons to draw from this example. First of all, the goal was clearly stated: We need to more efficiently use our space or people. We’ve been consistently growing over the past several years, and if we are too cluttered, there’s not enough room for people. Everything in the office must be neat so we’re ready for customers or colleagues to visit at any time. A secondary goal was to know what we had in the office so we don’t unnecessarily buy more equipment. (I swear cables spontaneously divide and reproduce when left lying around.) Second, don’t limit people’s contributions. We made very few decisions for others. As long as everything got put in a place that worked, we made no restrictions on how any problem got solved. Any group or individual was empowered to find a place and an organization for anything they found that was taking up space. Third, positive peer pressure. We were all working together. No one could say they were doing something more pressing and skip out on the cleaning tasks.  I honestly think nothing destroys team dynamics more than some tasks are ‘beneath’ them. The end result from Friday is great. People have space to work individually, spaces to collaborate. We don’t have to move monitors and cables in order to find space at a desk. And everyone had a hand in it. The more experience we get with Self-Organizing teams, the more impressed we are. You should try to experience it yourself.
Created: 1/17/2012 9:44:16 PM

While at CodeMash last week, both BBC and ZDNet published stories about the use of booth babes (BBC’s term) at conferences.

We don’t hire models for our booth at conferences, and we’re not going to.

TLDR version: It would misrepresent our company.

OK, if you’re still with me, here’s the lengthy version.

Problem 1: It gives the wrong impression about the company image.

This is the most important issue. We’ve got a great workplace with mutual respect among all our employees, male and female. Hiring models for a conference booth sends messages, subtle and not so subtle, about our company’s attitudes toward the roles of men and women in our business, and our company. Close your eyes and imagine a female software developer at GoDaddy. Their ad campaigns have affected your impression, and probably not in a good way.

When you execute a marketing or advertising campaign, you must live with the impression you’ve created. You don’t get to say “No, no, that’s not really us. We just did that to get your attention.” You’ve created an image, and you’ve associated that image with your company. Your prospects (as customers, colleagues, or employees) form their image of your company, your culture and your values based on the tools and images you use in your marketing and advertising campaigns.

If that image is not correct, you must work doubly hard to correct it. You must not only continue to build your positive brand image, you must live down the negative impression you’ve cultivated. It’s hard enough work telling the world how great you are. Don’t sabotage it by telling the world how bad you are.

The obvious reason we don’t use models at conferences is that it’s wrong for us. It works against our culture, our values, and the professionals (both women and men) that work here.  For the same reason, we don’t use models on our website. The photos that you appear are people who work at SRT, either now, or in the past, when the photos were taken. But, this is the part where some marketing professional usually says, “I agree, but it works. We’ll do it anyway.”  So let’s move on to why I believe it doesn’t even work.

Problem 2: The increased traffic does not indicate increased interest in your business. It indicates increased interest in models.

Suppose there are 75 people at a 1000 person conference who may be interested in what we do. Our goal, as a business, is to maximize the quality time someone spends talking with those 75 people. Nothing else really matters to the business as a whole.

One serious challenge is that you don’t know who those 75 people are. Standard marketing logic says that if you get the highest number of people stopping by your booth, you’ll get the highest number of possible prospects. That may be true in certain markets, and at certain conferences, but I don’t think it applies all the time.

Suppose we hired models to work at our booth. I have no doubt that we would have more traffic. There would be, however, two problems: First of all, a lot of that increased traffic would not be there because of what we do as a company. The additional visitors would be interested in the models. They are probably not in that 75 attendees I mentioned earlier that are actually good prospects. All the models have done is increase bad traffic and make it harder to spot and have real conversations with the real prospects in the crowd.

Problem 3: It drives away people actually interested in your business.

I’ve said nothing about the makeup of the 75 attendees actually interested in us. How many may be women that are turned off by a marketing strategy right out of “Mad Men”? How many, men or women, would be turned off by that image? How many might be interested in a deeper conversation about software development than they would be likely to have with a model?[1] Would they visit, or would they avoid the booth entirely? Real prospects may decide there’s too much traffic, and just ignore it altogether.

So what will you see at our booth?

We will demonstrate something interesting about us and our thoughts on software development. This last week at CodeMash, we demoed an original game built using the Microsoft Kinect. We did that because we believe there are interesting opportunities to use the Kinect in many applications; it’s important for us to demonstrate that we are already learning this. That’s a key part of the message: Our company stays at the forefront of technology trends, and is often even ahead of our markets. Our technical employees are given time to investigate these new ideas and build software that shows the result of these investigations.

In years past, we’ve shown mobile applications, cloud based applications, and a game controlled by the wii remotes. I don’t know what we’ll build next year. We’re still planning that.

Everyone at our booth works for SRT Solutions. Depending on the conference, they may have a more technical role (like at CodeMash), or a more business oriented role. It depends on the audience, and the conversations that will likely occur. Anyone you see at the our booth represents the company with their knowledge and their professionalism.

You’ll see people dressed pretty much like a normal work day. In fact, if anyone asks for guidance, we’ll say “dress the way you would to attend a customer meeting.” That’s consistent with our culture and our values. And, it’s the same advice regardless of the questioner’s gender.

Do I have a point?

Personally, I believe that the way you market yourself, or your company, is about more than simply generating a high number of leads. Your marketing creates an image of your company. If you’re successful, your marketing imparts that image to many different prospects: customers, partners, employees, and more. You don’t want to live down a marketing campaign that is at odds with your company culture. You’ll attract too many of the wrong prospects, and too few of the right ones. There’s the common phrase that says “half of all your marketing is wasted, you just don’t know which half.” If your marketing is at odds with your values, the sad fact is that all your marketing is wasted.

[1] This is not to say that models are not smart. I’m just saying they know less about software development, and our business, than our employees.

Created: 12/9/2011 7:33:03 PM

Earlier this week, I read two interesting articles on the importance of software and developer talent to future economic growth and prosperity. They are particularly important because I’ve been asked to participate in some of the talent initiatives Michigan Governor Rick Snyder announced last week.

Let’s start with the Forbes’ article “Now Every Company Is A Software Company” The deck quote ties it directly to Michigan, “Ford sells computers-on-wheels”. The thesis of the article is that no matter what business you think you are in, you are in the software business. I’ve been saying this for almost a decade. Are you developing innovations for healthcare? You need software. Are you in advanced manufacturing? You need software. Entertainment? Software runs that too. Marketing / Branding / presence? You better have a social media and internet strategy. That takes software.

Businesses have to be incredibly smart about creating software that provides true value for their business, and leveraging commercial software in other areas. Our customers don’t ask us to build everything from scratch. There’s no return on that investment. On the other hand, they can’t create the kind of innovations they need without some custom development. If all they do is use software that is commercially available, they can’t differentiate themselves from their competition.

From this perspective, I’m impressed with the emphasis on the software industry in Gov. Snyder’s talent address. Software requires less capital, and a high percentage of that capital goes to pay wages for developers. Software business investment provides a very quick and very high return to the overall economy.

Next, there’s an article in Forbes about the rise of Developeronomics. There’s a lot of hyperbole in this article regarding developers, money, and talent in general. It is well written, and it is a fun read. The core thesis though is very good: Good developers are valuable.  Really good developers are really, really, valuable.

This paragraph sums up the software developer scene well:

In the midst of a thoroughly gloomy labor market, the genuine desperation you see in the software talent wars is almost surreal. Almost every day, I see big companies, little companies, entrepreneurs, wannabe entrepreneurs and even venture capitalists join in the hunt. The talent hunters infest LinkedIn, troll Quora, and trawl Facebook and Google+. Cartoons of homeless-looking CEOs holding up signs that say “Looking for a technical co-founder” are doing the rounds. Heck, I am one of these talent hunters (any star iOS developers out there interested in working with me?).

That paragraph sums up the strategic importance of software developers. It’s important for companies, for local economies, for regional economies, and even for nations. It explains some of the importance of the ‘10x’ effect, coined by Fred Brooks: The best developers are an order of magnitude greater than the average developers. There’s also a ‘-10x’ effect, where the worst developers are capable of dragging down entire teams.

In addition, developers more and more now understand their economic value. They will explore the market, locally, regionally, nationally, and even world wide. They will attract their fair wage, or higher.

But of course, the best developers are interested in benefits beyond money when they pick a job. As the author points out, a developer’s skills have a relatively short shelf life. It’s career suicide to get stuck in an aging technology where career opportunities are slim.

Let’s tie this to Michigan’s talent initiatives.

There’s a serious disconnect between the developers currently seeking jobs, and the technical skills employers are seeking now. As a reader of my blog, I’m sure you’re familiar with many of the skills that are in demand: .NET, Java platform, mobile, web, tablet, cloud. The current applicant pool has a very different skillset: AS400, mainframe, COBOL, and so on. That’s the reason for several of the programs:  To address the shortage of developers, the state needs to update the skills of a generation of developers whose former employers did not stay current with modern software development tools and techniques. (As an aside, there is a corollary with business failure and the absence of a coherent software strategy. More on that in another blog post). There are two very important goals for this program. The first is to teach these developers the immediate skills they need to become employable in today’s software job market. The second, and far more important, goal is to reconnect these developers with the area software community. If they stay engaged, and take control of their own career, they will continue to update their skills, and continue to be relevant to the current job market. That will be the major win, to teach a much greater percentage of our software developers to stay relevant. The Forbes article discusses “The Lifecycle of Software Talent”, where developers grow more and more skills, but eventually becomes an expert in some ecosystem and never move on:

As a developer ages, and finds it harder and harder to switch technologies, at some point, he or she is considered hooked for the rest of their natural lives to some technology — Java or C++ or the Facebook API say — that they can be expected to grow old with. When a technology hits that point of maturity, talent that’s hooked to it starts getting devalued along with falling retention costs. The buffets become skimpier, compensation drops, churn is lowered, and the talent retires into the sunset with the technology. It’s quite poignant really, like a crew going down with a ship.

You have to fight that. The best recommendation (from the same article): “The really talented ones retain an evergreen ability to reinvent themselves around the latest, youngest technology layer, seemingly at will.” 

The software landscape in Michigan is the legacy of a generation of developers that did not do that, believing in life-long job security. The current situation, and the programs to address them, should serve as an example to developers, young and not-so-young, to follow that advice and continue to invest in relevant skills throughout their entire careers.  The more we grow a modern, talented software talent pool in Michigan, the more our region will prosper.

Created: 11/30/2011 3:52:37 PM

I don’t often review business books here, but “Good Strategy, Bad Strategy: The Difference and why it matters”, by Richard Rumelt is an exception.

For my audience, the best feature is that Rumelt is an engineer by training. He explains strategy from an engineering and scientific perspective. He begins his discussion by going over examples where a mission, or a set of buzz-word heavy press releases substitutes for strategy. From that moment on, you know this is not the normal business book. He picks apart such empty direction with the precision of an engineer, or a dilbert cartoon.

That first part of the book is a quick read, and quite humorous. Its value is in preparing you for the second and third parts of the book. That’s where the real value is.

The second section “Sources of Power”, describes where you can find leverage, or power, that enables a well-thought out strategy to succeed. You’ll learn to recognize drivers that can be part of a great strategy. Most of all, you’ll learn the elements of any successful strategy. On almost every page, I found something that I could apply immediately, and I’ve already found myself thinking through his examples and applying them to our current environment.

The final section “Thinking like a Strategist” provides insight into how to use your brain to evaluate strategies, and to create your own good strategies. In addition to learning to recognize a good strategy, you’ll learn how to create and execute good strategy. You’ll finally learn how to benchmark results of executing a strategy. Most importantly, you’ll gain insight into when and how to consider modifying, or even replacing a strategy that is not giving the results you hoped for.

It’s not often that I read a business book, and walk away thinking “I can use this immediately”. This book gave me that feeling several times. I was constantly finding new ideas, new techniques and tools to help me running our business. It’s well worth the read.

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.