Okay, maybe I am overselling our upcoming presentation a little bit.

Brian Skory (Technical Staffing Specialist) and I (VP Operations) bump into the same issues over and over again when we are working with candidates for job and contract openings.

They fall into the following classes:

Class #1: Resume needs work. It’s too long, too short, not organized well, lacking in details, etc.

Class #2: Candidates want to pump us for ideas about how to find opportunities.

Class #3: Candidates make blunders in interviews because they aren’t well prepared, which probably comes from a lack of familiarity with current interviewing styles and conventions.

In truth, Brian and I answer the same questions, give the same advice, pull our hair out over the same issues pretty regularly.

So we decided to create a presentation that addresses a lot of the most common issues and questions.

Now what, you would rightly ask, are our bona fides?

Brian has been working directly with our clients and our candidates for several years. He gets feedback about why clients don’t like candidate resumes. He gets feedback about why clients are passing on candidates. And he fields a lot of candidate questions. He is a wealth of practical knowledge that comes from a wide variety of managers.

I have an interesting mix of experience. I am often a hiring manager myself, because I am read resumes and interview candidates for the software development projects that we are awarded as outsourced contracts. In addition, I still process the enormous influx of resumes we receive in response to job and contract postings when our regular recruiter, Ursula Kellman, is on vacation. Like I’m doing this week. When you read 50 resumes in a day, day in and day out, you start to develop a very good sense of what communicates and what does not.

So Brian and I have a nice mix of experience to give some very practical advice. But only for the high-tech workers (Web, Software, Embedded Systems, Network Engineers, Technical Managers, etc.). Accountants and teachers are not going to find our advice very useful. By the same token, listening to generalists is not very helpful to high-tech workers!

The presentation will be held on March 24th from 6:00 to 9:00 PM at Ann Arbor Spark. The registration page can be found on the Ann Arbor Chapter of the Association for Women in Computing’s Event Calendar.

Monday night the Ann Arbor City Council met to discuss the new Google Fiber, ultra high speed broadband network.  It was a very big turnout, and you can see a number of the participants and their thoughts on YouTube.  The current Google Proposal will increase both the reliability of our current networks and the speed by somewhere around 100 times, making a lot of applications and interactive products possible that aren’t currently viable.

This type of infrastructure would have profound positive impact on the region, greatly giving us the advantage in a number of areas.  In our own field, I would expect this would facilitate the development of a number of new high speed Internet applications, built well ahead of the worldwide competition in this space.

The City of Ann Arbor and the University of Michigan are jointly working on a proposal to Google, which will be submitted before the deadline on March 26th.  Community support is a major part of the proposal, so they are asking for lots of help from everyone.  The organization A2 Fiber (@a2fiber) recommends a number of things you can do, including creating your own YouTube video.

It seems to me the most straightforward thing to do would be to write something, such as a tweet or a blog post about this, and then go up to the Google Fiber for Communities site and recommend Ann Arbor. As you’re filling out the form, you’ll see a place for a link to your tweet or blog post or heck, even your YouTube video.

If you’re reading this and your community is also trying to submit an RFI, then certainly get involved.  If not, please consider supporting Ann Arbor’s bid.  This is not just a good opportunity for Ann Arbor, it’s a good opportunity for the region as a whole.

I’d like to question some decisions made in tough economic times. When the economy gets soft many companies look at software projects for possible cuts. And, usually, they look at non-developers first. The thinking goes, “if I have software developers I can still develop applications. I like having dedicated architects, business analysts, project managers and QA staff, but I don’t really need them.” Depending on circumstances, that may prove not to be true.

Software developers provide the technical expertise to make applications run. But non-developers provide the higher level meta-intelligence about the processes being automated, the environment in which they will integrate, the best delivery method(s) for that environment and the necessary steps to ensure quality. Without them, teams may do a great job of delivering software that doesn’t solve problems or automates unnecessary processes. Predictable delivery and quality often get lost in the mix.

This is not to say developers don’t understand the value of testing, etc. But their role is highly technical and needs to be focused on turning technology into magic. Non-developers fill roles that are both technical and process: they focus on the connections between systems as well as human and business factors. In many cases, it is this “human intelligence” that makes the difference between cool software and applications that really meet business needs.

So I’m thinking companies don’t do themselves any favors by cutting the environmental, process and human aspects of a development team just to keep writing code. Often times, the worst trouble a development team can have is when they don’t understand the problem they are solving or how it relates to the rest of the business.

We came to CodeMash with pretty high expectations, given our experience in 2009, but the CodeMash team just blew them all away. Thanks to everyone who put on CodeMash 2010. This was Stout’s fourth year and we’ll be back in 2011 with the Stout Software Smackdown 2011 – Cage Match, Last Programmer Standing event and a lot more.

Here’s some pictures of our great time at CodeMash 2010:

Yes, that smiling man is Stout’s own Brian P. Skory. Brian manned the booth at CodeMash 2010 almost all of the time (thanks Brian) while the rest of the team, John Stout and I, got to do the fun stuff.

One of the great things about CodeMash, and CodeMash 2010 was no exception, is how many fun tech conversations you can have. Here at our booth, Brian and I are talking with Jon Woodard of Inner Circle Media in Ann Arbor about an iPhone application we have been dreaming up.

Here I am getting in the way while Brian manages the crowd.

Here I’m getting ready to kick off the Stout Software Smackdown.  This was our first year putting on the Smackdown.  So many people at Stout worked overtime to put this together and it really paid off.  We had a lot of fun and now we’re excited to do it all again next year at CodeMash 2011.

A set of pictures from what was obviously our favorite event at CodeMash 2010—The Stout Software Smackdown—23 minutes of pulse pounding software development.  Action packed programming that has never been seen before.

And the winners of the Smackdown: Kevin Berridge, Benjamin Lee & Josh Schramm.

I attended a pre-proposal meeting last week, where a very large company was asking their vendors and other interested parties to comment on and ask questions about their software selection process. A group of five in-house managers had been assigned to create this process and the written specification. Now the five of them were present to attempt to explain and clarify the written document we all had in our hands. Just for a little context, the audience was composed primarily of high-level managers representing vendors or their supporting partners. Most of them seemed very strong in understanding the proposal from a financial and business implementation perspective.

Very early in the extended Question and Answer period, the issue of Cloud Computing came up. The preliminary spec was asking that the next generation of software be more “Cloud-like.” The audience was obviously looking for clarification. Remember this wasn’t a technical audience and even if it had been, the specification wasn’t really clear. The moderator of the panel asked if anyone else on the panel could explain Cloud Computing. No one volunteered. The audience laughed a bit. He smiled and then asked if anyone in the audience could give us a brief definition. Dead silence. He smiled a little wider and said, “does anyone here know anything about Cloud Computing?” That was it for me. I had to put my hand up.

I explained to the room that Cloud Computing is the idea of delivering common business applications like word processing, spreadsheets, contact management, and so forth online, accessed from a Web browser. The applications and the data are stored on servers that are somewhere on the Internet—hence the concept of the cloud. A person or a business should be able to see the computer world as a cloud, where they can pick and choose from the applications and services they need and want at the moment. I then went on to describe some of the current business models that were out there. I finished by talking about the current public offerings like Amazon, Google App Engine and Microsoft Azure. I was kind of proud of myself for trying to connect with them on a business level and from comments I later received, I think what I said was helpful. Unfortunately it didn’t really address the specification or a real need by this group. I didn’t realize that at first, but as I sat down, I started really wondering what the panel meant by making the software more Cloud-like.

The company already has a first generation version software product. How is that product delivered? As a Web application. Since one great example of providing software on-demand as a service is a Web application, the existing product is already on track as being “Cloud-like.” Even more strange, the ultimate users, a number of in-house business units, pay only for what they consume. This is very much according to the Cloud Computing “metered service” approach. Yet despite these two critical Cloud elements, they needed the next generation to be more Cloud-like?

So what was I missing? What part of the Cloud model were they talking about?

As the meeting continued on into the afternoon I kept getting little bits and pieces of information. I talked to 3 of the 5 panelists personally. I even took a 5-minute break to read the Wikipedia article on Cloud Computing and do a little Web research. I’ve been an active developer of Web Services and Web Applications for almost 6 years now, so I feel I’ve been a genuine contributor to the current Cloud infrastructure. Never-the-less, I left the meeting convinced that I hadn’t really understood what piece of the cloud they were missing.

A few days later, as I was reading my nth article on the Cloud, I stumbled across what part of the Cloud they were having a problem with.

At the meeting I had been told something by one of the panelists about what it takes for a business unit to adopt this software.

The company requires its business units to use software only from vendors who are on the “approved” list. This requires a time consuming evaluation period including things like face-to-face presentations and pre-scheduled software evaluations. Mind you, this is even for a Web application that is hosted off-site and uses a pay-as-you go model. When a business unit chooses a new vendor they need it to work with their own back-office accounting and their own business rules, so for each “roll-out,” the vendor, along with the business unit, have to customize for the business-unit’s back office. Just to be clear, every business unit has one or more of their own unique back office applications.

So here we have a metered, no-install Web application, but it can take over a year to adopt? It’s crazy really. I think the Cloud piece that they need next is the adoption piece.

Adoption is a key element of the Cloud. A Cloud offering needs to have the quickest and most efficient adoption possible. Any Cloud offering should aspire to little or no adoption time. This allows for the end user to turn on a dime and change to another software offering in the blink of an eye. If they can’t do that, then the software that they are using is bound to become stale.

To me, there are two problems to solve. First, the evaluation period needs to be cut down. Second, the back-office customization needs to be dragged into the Cloud age.

I would replace the current evaluation, with an iPhone App Store approach. When a vendor submits their software for review it goes through a set of automated tests to ensure compliance. If the software passes the tests, then after some small subjective evaluation (1 or 2 hours at the most) the software is placed into the hands of any and all business units.

Addressing the back-office seems pretty straight forward. Even though each business unit has its own back-office, there really is only so much information available from the vendor software, so to me, that’s where to start. Build a Web service into the vendor’s software that allows any and all back-offices to request and receive the information they need. To me, this would be a simple W3C compliant Web Service. This “channel” into the needed back-office information would be part of the specification, and to be considered compliant, each vendor would have to implement it.

The first migration would still be difficult, but a lot easier than it would have been. Just using a standard Web service makes things go smoother, speeding adoption and reducing errors. The real advantage though is that once this back-office connection has been written, the business unit can switch to another vendor in the blink of an eye.

With adoption effort, time and cost down to almost zero, a business unit could quickly change from one vendor’s software offering to another in the blink of an eye. This gives the business units a real advantage economically. It also is very helpful to the vendors as well. Vendors who give a good presentation and do good customization work aren’t always the ones with the best software offerings. With an inexpensive adoption model, vendors can focus their efforts on getting their software right and keeping it fresh into the future.

I was kind of skeptical of the Cloud model up until this experience. Not because it doesn’t make sense, just because it seems more of a buzzword than anything. Strangely enough though, when I was forced to look at this project from a Cloud perspective, I discovered something very useful. The Cloud means many things to many people, but when you look at something like software adoption, I think most would agree that zero-effort adoption is definitely the Cloud way.