Thursday 19 September 2013

Traits of Rock Star Software Engineer


Question: Who you want to hire for your team?
Answer: A Rock Star Software Engineer.

I am at a juncture where I started thinking about forming the “A team”. We all know the importance of “P”. Fortunately I have had the privilege to work with real “Rock Stars”. I pinned all the traits which is common to all those.

Tagline of great companies reflects what they stand for. Thought it will be a great Idea to map them to traits of a “Rock Star”.

I’m lovin’ it (McDonald's)

They love what they do. All good programmers are passionate artist. Artist’s gives utmost importance to the details, perfection and finishing touch. Takes pride in their code.

Look for good story tellers. When you read their code you feel like you are reading a story. Story will be very precise and concise. Good documentation, unit test and following fundamental principles of software engineering will be quiet natural for them.

Evaluation: Ask how you will mentor a new joinee into a good software engineer. Ask for importance of unit test, principles and a practical stories.

Just Do it (Nike)

For Agile working environment we need rock stars who can just do it. No non-sense. They will find ways to do it rather than ways of not doing it.

No reinventing the wheel. They will do it the smartest way. (Design pattern, framework, copy code)
Just do it also means they learn quickly and take tasks to the finish line.

Evaluation: Ask about application of patterns and reasons of selecting frameworks. Ask about an experience of doing something out of comfort zone.

Think Different (Apple)

They have business acumen. They are not code factory. They know what they do. They will have understanding of the bigger picture. They ask difficult questions and have to be themselves convinced before doing it. They think different and come up with simple and innovative solution.

Evaluation: Ask about projects end to end workflow and business value. Check if he is asking questions to clarify and does story telling. Give a problem which sounds complex and look for the approach.

Imagine it Done (Unisys)
Imagine it, consider it done. Great problem solving skills are essential. Approaching the problem in a disciplined manner is trait which make them different. No follow-up is required. They will make sure that the whole team is orchestrated and informed.
Evaluation: Look at the approach of problem solving. Ask about deployment and co-ordination with other teams.
Because You're Worth It (L'Oréal)
Confidence is the super trait they possess. They knows how much they are worth. You get what you have paid for. Money is not the only thing which attracts them they believe in something and they stand for it.
More number of developers are not equivalent to a Rock star. For that matter sometimes they are irreplaceable.
Evaluation: Is he begging Or He know what he wants. Confidence comes with knowledge and trust. Don’t confuse with great communication skills.

Betcha Can't Eat Just One (Lays)

They are curious people. They are aware of latest news in technology or internals of how things. They learned internals of operating system because they want to not because they have to. Data structures and algorithms will be in their blood (or will derive solutions from basic understanding towards existing principles).

When they don’t know they listen. They will not make others feel they know everything.
They will have projects which is not related to work. They always learn, imagine and innovate and do things differently. No complaints about absence of challenging work.

Evaluation: Ask problem solving question with application of data structures and algorithms. Observe if they listens, questions, and disagrees if required. Ask about contribution to open source or stretch projects or community contributions. (Gist?)

Connecting People (Nokia)

They are not ball of mud. They connect people. Rock stars believes that by mentoring and helping others you can add more brains and hands to yours.
They get things done. Again! They are not just code factory. They also helps software community in some way or other (Blogs, forums, open source).

But call them for a movie they might not come J

Evaluation: By now you know that.

Conclusion

You will get geeks, nerds.. but they are rare…The Rock stars!

Monday 9 September 2013

Steps towards software operability

The generic definition for operability in Wikipedia is “Operability is the ability to keep an equipment, a system or a whole industrial installation in a safe and reliable functioning condition, according to pre-defined operational requirements”. The definition seems to be applicable to critical application software deployments also. The clause of “pre-defined operational requirements” either makes it vague or makes the definition customizable.

An operable system not only satisfies business functionality for end-user but team behind it. For example for making an eCommerce site working 24X7 requires a lot of operability efforts in design to post-deployment phase.

The projects I worked in past couple of years demanded high operability. This made us think in different ways of designing and planning. The cost you pay for not having operability practices in place is very high. It can shoot your company into “Wall of shame”.

Tackling operability issues of your project require following acts:

Sell it first: Operability is inevitable, to which extent depends on the project. Try to get a deeper understanding of the operability requirements from your previous projects or similar projects. Prepare well in this phase, tough questions awaits you. What, How and When should be detailed to evaluate the need, extent, benefit and cost involved. Sell operability needs of your project to the management, it involves cost.
 
If it is an existing project you might stop here and continue the way you’re executing the project. Operability is nothing new it always existed and you might already have things in place. But please read phase two “Get the act together” to make sure that you didn’t miss anything while planning.

For management also this is critical phase to understand and justify the cost paid for operability especially in agile projects.

Get the Act together: Since we are past the phase 1 you are ready to “Get the act together”. This does not happen as part of business requirement it needs some extra effort in all the phases of development. It is strongly recommend to have a separate team which will enforce the principles of operability, build/customize tools and framework to suit your deployment. This allows focus, reuse and policing of operability. Having said that separating functional requirements and operability can be fatal to the project.
 
Operability team should improve the process/framework via continuous feedback. The functional team adopts the operability by infusing it into the business requirements.
Operability should be part of all phases of Software Development Life Cycle (SDLC).Let us look at each of the phase from operability perspective.
Design: Define clear milestone goals for operability. Operability goal can be in following areas
1.       Performance
2.       Scalability
3.       Security
4.       Recoverability
5.       Backward compatibility
6.       Deployment
7.       Rollback
8.       Monitoring
9.       Reporting system health
10.   Trouble shooting
11.   Testing the points 1-10
All of the above should be present in one form or other in all your critical projects. If not remember about “Wall of shame”.

Development and Testing: Practically this might be the longest phase in most projects. As far as operability is concerned this should be the shortest one. If operability tasks is taking longer go back to operability team. They need to fix it.

The main intention of this phase is to follow instructions/guidelines and make sure that next phases doesn’t require human intervention. You should never lose a chance to automate.
Ensure to log in standardized format across all applications as appropriate to enable monitoring and troubleshooting in next phase.

Testing for scalability, performance, backward compatibility, rollback has to execute as planned in previous phases. This is your last chance to avoid catastrophic failures. Collect as much information as possible and do analysis of the variations from baseline during performance/stress tests.

Deployment: Deployment should be automated with rollback plan in place. For high  availability you might also consider Business Continuity  Plan (BCP).Auditing of the deployment and production testing will also help to improve the overall operability.

For complex deployment auto provisioning system can be used.It is generally good idea to do dry run before the actual deployment to make sure that all environment specific attributes are taken care of.

Watch Out!
I would say this is the most critical stage in operability. In this phase application is monitored and feedback is given to the system.
Tools required for this phase can be built or off-the-shelf product can be used. The logs collected should be stored to do analysis and reports.

Monitoring: Monitoring trending errors, performance parameters, application parameters and system parameters critical to project happens in this phase. Servers, Load balancer, Storage, Network, and Switches are possible candidate for monitoring. Use dashboard/alerts for monitoring the application.

Troubleshooting: How good you’re in “Get the act together” phase is usually defined by how fast you’re able to trouble shoot production. Design to make sure that the exact module which failed is identified immediately.

Classify the issues identified in this phase and formulae strict guidelines for the action. Also feedback should be given to phase 1 and phase 2.

Cloud Computing
Does the above applies to cloud computing?Absolutely.
At least in SaaS I would expect the provider to have a great operablity infrastructure.

Take away
Consider operability requirements as a critical deliverable. The key take away while designing and architecting the system are.
  • Evaluate: The extent of operability
  • Specialize: Form a specialized team for operability
  • Automate: Remove manual steps
  • Feedback: Give actionable feedback to the system