Friday, March 6, 2015

You're not going to jail rookie!

For the past years, I've been to universities to talk with students and I've participated in a few tech talks with recent graduates. Last week I was speaking at a conference under the topic:

"The new challenges for recent IT graduates"

It was an interesting discussion on the new trends, how do you refresh your knowledge after graduating, how technology adds value to other industries, how universities adapt do constantly evolving technology, the IT market, etc. There's a pattern on the questions that the "non-experienced" ask, but there's one question that ultimately pops in the end when everyone is more relaxed and lost the fear to speak up:

"What if I fail and my code ends up messing everything?"

One graduate once shouted "Is it possible for me to go to jail?" Well, yes. But it's more likely for you to win Euro millions. In the live discussions normally comes out a short version (that will be in the end of this post), but here's the longer version. Keep in mind that this post is towards recent-graduates.


It's a delicate and controlled balance

According to the Project Management Body Of Knowledge (PMBOK 5th edition) by the Project Management Institute (PMI), "Managing a project typically includes, but is not limited to:"
   (...)
    Balancing the competing project constraints, which include, but are not limited to:
            Scope
            Quality
            Schedule
            Budget
            Resources
            Risk

Simply put, if one of these constraints changes it is likely that it will affect one or more of the others. For example, imagine that the original asking was a mobile app to work on Android phones. Now, the client wants the app to work on iPhone as well. Scope is now totally different and unless you do something with other constraints, your project is on the fast track to became a flop. Even the Risk analysis has to be done again to accept, deny or mitigate new risks associated with the new scope. This 6 points project constraint is an evolution of the most basic triple constraint model:

Project Management Triangle

Let's focus on this more basic as it's enough to explain. Considering these three points, how would you position your student works? Can you compromise the schedule and delay your delivery by three months? You'll probably fail the class by that time right? Is cost relevant to you? Did you measure how many hours you took to do the work? It were "a lot" right? But if you needed to add another 4 hours, you would: "Cost" (on human resources – you) was "irrelevant", you wanted to deliver the work on time. Was it a bulletproof piece of work? Probably not. Analysing the "real world" is no different.


The Impact (aka short version)

If you were developing a small eCommerce Website to a local store, do you think they would be available to pay whatever necessary to put a small website up and running? That might drive little business? So, Cost is probably one of the most important issues to them as opposed to scope (if the site doesn't have real amazing graphics, no big deal). On the flip side, what do you think is the crucial element for a new medical device or the software for a new Jet fighter? Cost isn't probably the biggest problem, but scope and quality is vital. That's why a new medicine can take a decade to be released and implies thousands of tests. So depending on the work, industry, etc, the constraints weight differ and the focus moves around:

Project Management Triangle

So, in the example of the Local Store, the Cost is probably the focus, compromising some Scope. On the other side, the healthcare industry has it's focus on scope and is willing to compromise Schedule and Cost. So, as your work has more impact on something, either a business or people's lives, the risk of some crazy code getting into production environment drops dramatically. It tends to zero on extreme cases like the pharmaceutical industry (healthcare), aviation, military. These three are examples of industries where "a bug" cannot make it into production. An Airbus A380 with a bug and a plane crashes? No way right?

This level of commitment implies some trade-off and it's only possible due to years of operation. How was the Quality Assurance in your student works? You basically had a development machine, your colleagues and some source control? In, let's say, a Bank or an Insurance Company, it's not that simple. Here's a real example from a Telco company:

    You develop some feature in your machine, then it goes to the team's development environment, then it goes to an Integration Environment or similar where all the teams integrate concurrent developments. Side by side with this, there's Source Control Systems and Unit Tests (with or without regression tests). Next step is a certification environment where another team asserts that everything is "correct" from the users perspective. After this, it gets deployed (by another team) to a Quality environment at which point the client has to give the green light to go into production. Final steps: Deploy to a pre-production environment to assure that the deployment process is independent and clear, with no machine related issues and that "no surprises will arise at 2am or whatever" when deploying to production. If and only all the previous steps are "ok" the software finds its way into production. And all this is required for the smallest feature. Not only that, but there are several people and teams involved and for the latter steps of this process a form submission is required with deployment steps, impact on operation, risk analysis, rollback procedure (in case something goes wrong), etc.

This is just an example, but as you can see, changing the color of a button it's not that simple. And that's the good news. All this adds overhead, but a required overhead to assure high confidence levels on new developments.


So, keep calm. Don't be afraid of your skills.


Also see CMMI.