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.

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.

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.

I thought our recommendations would be of general interest, so I’m posting them here. This is still a work in progress, so I’d appreciate any thoughts from my readers.

Sprint Meetings

We recommended moving away from a process where every team attended one large sprint meeting. Every team planned their next sprint during these large meetings. Our customer was concerned that there was very little energy in these marathon meetings. The main reason was that for many attendees, over 75% of the content was not interesting: it was about other applications. The level of detail was too deep for members of other teams. By scheduling project-specific sprint meetings, each meeting had fewer people, and those people were engaged in the activity.

To make sure that the voice of the customer was represented, we recommended that one member of each application team attend the framework team’s sprint meetings.

To make sure that the framework team knew of any issues relating to each application, we recommended that one member of the framework team attend each application team meeting. (Although not necessarily the same person. That would be a lot of meetings).

We made this recommendation because sprint meetings are in depth, and project focused. We feel it’s important to have all attendees engaged for the entire meeting. We wanted to reduce the waste associated with attending meetings where someone is not really contributing.

It did raise the energy in the project meetings. It also brought some concerns.  Everyone felt this decreased the communication between application teams. That could lead to code duplication, missed opportunities for reuse, and siloes of knowledge.

On to Standups

Standups are a mechanism to communicate to everyone any progress, and any issues. We recommended having all the application teams and the framework team attend the same daily standup. That’s about 30 people, but it can still be a short meeting, if everyone follows the rules. We’re finding two main advantages to this process.

If someone is stuck, a larger group of peers hears about the issue. That increases the chance that someone will say "I can help." Issues get solved quicker.

The framework team is becoming much more efficient. Imagine someone on an application team makes a feature request of the framework team at one of these standups. One of three outcomes are possible:

• No one says anything. That likely means that no other app needs that feature. Maybe that feature is better implemented in the app team’s code base.
• Other App teams say they need (or will soon need) that same feature. That information helps the framework team prioritize requests.
• Another App team says "we’ve already built that feature." Now, the work changes from a new feature to refactoring code (and associated unit tests) to move it from the application’s codebase to the common framework. That avoid code duplication, and means the framework team can release the new feature more quickly.

It’s working quite well so far.

What have you tried? How has it worked?

Bill Wagner and co-founder Dianne Marsh started SRT Solutions in 2000 with an eye towards keeping software development in the Ann Arbor area.

Photo by Mark Bialek | For AnnArbor.com

“Everyone you talked to in the first half of the 2000s said, ‘No no no, don’t go into that space, the jobs are all going offshore, the wages are going down,’” he said.

“Now we’re reaching the point where we see an incredible shortage of people with computer science backgrounds who graduated from high school from 2004 to 2008. Those would be the recent college grads or the people with 3 to 5 years experience, we just don’t have those in the numbers we should.”

“We’ve never formalized it as a mission statement, but what we’ve always been behind is doing whatever we can to help the software industry in this region grow,” he said.

The company’s newest effort towards increasing programming proficiency in the area is a Developer Growth Infusion training series planed to launch Jan. 16.

“We like to think that this course will complement courses such as [Ann Arbor SPARK’s] Shifting Code and companies that are hiring new graduates,” Wagner said.

“Those types of people will have a lot of the basics, a lot of the theory, but they don’t know what a professional software development organization looks like. So we’re trying to augment their training and be the next stage in these individual’s development.”

SRT already hosts training sessions for companies that want to train their software staffs in new and emerging technologies. Wagner hopes that companies will sign their programmers up for the new courses as a way to make sure they stay on the cutting edge.

“From a company standpoint, you need to invest in your people. It’s a good retention strategy,” he said.

“If you’re going to be a company that helps your employees grow, you’re going to be a better destination employer, especially as the market for software skills keeps tightening up.”

Individuals also can sign up for the classes on their own. With new software languages and hardware products being developed all the time, Wagner said it’s vital for programmers to keep up with the newest technologies.

“One of our concerns is that there’s such a shortage of programmers that people think you can have great success by taking a couple community college classes and the Shifting Code workshop,” he said.

“Those are good on-ramps, but they don’t go deep enough to allow you to have a good long career in the industry. Development moves too fast, and there are too many things that happen too quickly for someone without a really strong basis in computer science and theory to keep up.”

Each half-day session costs $300, with a $250 group rate for groups of more than 5. The first class, scheduled for Jan. 16 will deal with C# and .NET 4.5 programming. Wagner said he plans to run one session every two weeks.

“There’s more and more recognition these days that the software sector is a strong sector that people should want to be in,” he said.

“People say this last recession was a ‘great recession,’ but for many of my colleagues it was not nearly as bad as the dot-com burst. Software developers really skated through the last recession. The sector kept growing, and it’s going to keep growing. We all need to keep learning to keep up with it.”

Ben Freed covers business for AnnArbor.com. You can sign up here to receive Business Review updates every week. Reach out to Ben at 734-623-2528 or email him at benfreed@annarbor.com. Follow him on twitter @BFreedinA2

Continue reading Software development company SRT Solutions offers new public training courses ...

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.

Wed Nov 14th:  Windows 8 / VS 2012 Launch and InstallFest

This coming Wednesday, our local .NET developer group, AADND, is hosting an install fest / launch event for Windows 8 and Visual Studio 2012.  You can come and install Windows 8 and Visual Studio 2012 on your box. A number of people that have already worked with Windows 8 and VS2012 will be on hand to help, and to provide guidance. I’ll be there to help and to discuss the Open Source environment for Windows developers.

Thursday Nov 15th:  Doing Privacy Right. A workshop for app developers.

SRT Solutions is teaming up with the Association for Competitive Technology and the Mobile Technology Association of Michigan to raise awareness of privacy issues as it relates to mobile and app development.  We’ve got development experts, FTC officials, and legal and policy experts to help navigate what can be a complicated landscape. It is important information for developers to have at their disposal. I’ll be saying some opening remarks, and helping with Q and A on Windows 8 development.

Saturday Nov 17th: 1DevDayDetroit.

And the week ends with a full day of development goodness at Cobo Hall in Detroit. Dave McKinnon and Dave Giard have put together a strong program (well, I’m speaking too), and it promises to be a great day.  I am speaking on async / await features in C# 5 and what that means for .NET developers.

The first two events are free, and a great way to learn and grow your development skills.  1DevDayDetroit is $99.00. Check them out. All three events do require pre-registration. 

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.

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.

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:

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:

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.