Why so many fail when trying to move to the cloud?

First of all, I am talking from anecdotal experience working mostly with the Mexican IT scene, but it’s not restricted to it, I have observed the same behavior on some US companies.

The last months I have been working with companies helping them move to SaaS taking advantage of the Cloud, my colleague at Scio consulting, Mike Dunham has written a series of posts “The Cloud, SaaS and the Total Costs of Operations” you can found here: part 1, part 2 and part 3 . This is a developer's point of view.

Microsoft and AWS in a lesser extent, both have information about their products, and how to use them, but one thing that is missing , there are no papers encouraging  developers to change their mind set to develop applications that take advantage of the cloud in terms of business benefits. We, the developers have to start getting more involved in the business side of our companies so we are aware of the challenges, the objectives and the market, how can we design and develop and application that takes our company to  business success if we are not aware of  those “boring” things?

Other thing that I have found, is that, as scrum is invading the startup scene and as companies are being dazzled by the scrum shine, the “fail” line grows faster. Don't get me wrong scrum has its place, but I won't use it for all the projects and I won't use it with all the people. I will use it on projects with people that already know and like each other.

Many architects and developers design and code the application the same way for on premise and cloud environments.  Most of those applications will fail when they need to scale because of their success and the only option to is to scale them up. To run efficiently in the cloud, many apps require changes and rewrites of some parts to run on a web farm.  How can architects and developers design and code for success if scrum and a big picture awareness can't live together?

So what is the solution? It is easy to say we need to design and develop for business success, but not as easy to implement. We have to learn and remember to design and develop applications to scale automatically on demand (elastic), always develop with operations in mind and remember that today ignorance and laziness is tomorrow's nightmare.

Software development is like cooking

One of the things that I enjoy other than spend time with my family and programing, is cooking, and I was thinking that I may enjoy it just because it's very similar to programing, seriously!.

I have always think about software development as Art, Craft and Science, cooking is the same, the result of you developing or cooking can be considered Art if you are a good craftsman, if you applying science properly and of course if you add creativity and imagination to the process, lets talk about other similarities between software development and cooking.

Software development and cooking process have some similarities:
First you want to fill a need or you want to create something new.

For software development:
- You need to define your goal, your scope, your budget.
- You define high level requirements:
     - You have platforms.
- You make some estimates.
- You develop something:
     - You have pre built solutions, that you can customize.
     - You have tools and frameworks.
     - The Actual development.
     - You test and debug your work.
- You validate your work.
- You publish your work.
- You receive feedback.
- You adjust.

Sample for cooking:
- Dinner/ 6 persons / 100dls
- Appetizer, Soup, main dish, desert:
     - Vegetarian, Meat lover:
          - Mexican
          - Italian
          - Etc.
- Preparation in two hours, 1lb meat, 5 tomatoes, 1 onion. etc.
- The actual cooking:
     - Frozen food.
     - Pans, knife, recipes, frozen vegetables, anything ready to use.
     - The actual cooking.
     - Taste, add salt, add water, etc.
- Ask a family member to taste your dish.
- Serve.
- Receive complements or complains.
- Take note and adjust for next time.

The actual development and cooking process is where a lot of things can make a significant difference, even if you are following a recipe, it's in that part where you can be creative, add or remove  ingredients to the recipe, cook for more or less time, etc. its also the most risky part, you made a mistake and it will be very difficult to fix it without having to start again, also the more you cook, the better you are.

There are also specialties, some developers are better working on the front end and others in the back end, as some chefs are better cooking deserts, salads, etc.

Software development and cooking are not precise, but you can make very good guesses applying some science to your process.

Presentation, consistence, smell, or UI and UX, presentation is one of the most important things for chefs, if the dish is very tasty but lacks of a good presentation, many people will not even would like to try it, the same applies for software development, your product may be a super cool idea, you may be using the latest technology and probably you designed some super fast algorithms but if your product don't have an interesting UI and a very good UX, nobody will use it.

I am pretty sure that there are many other things that make software development and cooking a similar process, but thats all that I can think for now.

Hiring developers...

This month we stared hiring developers, by the way, if you are a C# developer with strong knowledge of javascript(jquery nice to have) you can send your resume to hmatamoros@sciodev.com, anyways, we are hiring, I am in charge of most of the technical interviews and this time I am using a different approach for the interviews, let me elaborate:

Most of the times, in most of the companies when they perform remote interviews, the interview goes like:

Interviewer - do you know what is "X"(some obscure or new language feature)? -
Candidate - err (googling the question)...yes, sure!, I used that on my last project -
Interviewer - what does MVP, MVC, MVVM mean? -
Candidate - (googling)...answering.
etc., etc.

Some other companies(us included) use small problems like the famous "bizz buzz", and this is ok, but a developer is not going to be solving simple bizz buzz problems always!, so if you are relying on that kind of tests you are screwed, take a look to:

 for (int i = 1; i < num; i++)
{
     Console.WriteLine(i % 15 == 0 ? "FizzBuzz" : i % 5 == 0 ? "Buzz" : i % 3 == 0 ? "Fizz" : i.ToString());
}

does that tells you if I know OOP, if I know programing principles? does that tells you if I know how to apply some patterns?, of course no!, I also found that some guys that practice for programming concourses solve this kind of problems "easily" but their OOP skills are terrible.

The problem with many technical interviews is that those are not evaluating the skills and knowledge that the individual is going to be using on daily basis, thats why I started to use a slightly different approach, I still use the quick challenges, but I also put them some weird code and I expect them to fix it or comment what is wrong with that code, I also ask them to write some code like a simple repository, and also exercises that help me evaluate their OOP skills, like write a simple game engine.

The results so far are great, previously we hired some people that were not very good programmers, and what happens when you put some pressure on bad programmers? they quit or they just put everybody on trouble and we have to ask them to leave the company, why in the world would I accept a job if I know that I cheated using google on the interview? why would I take the risk of moving to a new city if I know that I am not qualified?, that's something that I will never understand.

Just to finalize, I know that I need to learn a lot of many things, but I am honest and when I don't know something I just said, "I don't know" and then I will put my self to study, I expect the others to do the same, our company always give the people the oportunity to learn, we just use the interview to know if the people is a good match for our culture and to have an idea of their skills.