|
Copyright: KGSS (Google search) |
Something related to an old post reared its head up again.
I talked about this topic a little differently earlier in my blog post, Thinking Through.
Some chat at work, daily stand-up meetings and elsewhere brought us to the subject of ‘estimations’. A much-maligned term, it is a usual subject of debate, unmet expectations and some heart-burn. In the usual SCRUM scenario, questions like –
- How valid are the estimates we put out in the SPM?
- When is a good time to revise the estimates?
- Why are estimates usually less than actuals? What if estimates were more than actual?
… and such others, usually are the epicenters of debate. After all, one person’s ‘estimate’ is another person’s ‘commitment’.
And this leads to questions like the following:
- Why do we estimate?
- Why is this a skill?
- If estimation is a skill, how do we claim competence in it?
Before I chew on the above, a general idea put up its interesting hand up in my mind. Yeah, and I stumbled upon it while browsing, after a chat I had with a retired Civil Engineer.
Lawyers cannot practice law without a Certificate of Practice (Sanad).
Civil Engineers cannot practice without a Certificate of Practice.
Doctors cannot set up a clinic without a Practicing Certificate.
Software is already driving cars, running machines. Who qualifies the capabilities of software engineers? Unless you want to certify a product as Safe (SIL Certification or other such Safety-Critical certifications), who should care about the makers following software development best practices?
The Institution of Engineers is the largest multidisciplinary Professional Body of Engineers. It was conferred with The Royal Charter, on 13 August 1935, which mandates as follows: “to grant certificate of competency whether under any Act of the Government of India or Local Governments regulating the conduct and qualifications of Engineers or other wise howsoever”.
Engineering Disciplines in which Certification of Professional Engineers awarded presently are:
Civil Engineering
Electrical Engineering
Electronics and Telecommunication Engineering
Chemical Engineering
Mining Engineering
Mechanical Engineering
Marine Engineering
Environment Engineering
Wonder why is Software Engineering missing here?
Basic Requirements for certification as Professional Engineers:
- Bachelor’s Degree in Engineering or equivalent recognized by Statutory Authority or Government of India;
- Experience of 7 years in engineering practice;
- Professional experience of 2 years in a responsible position of significant engineering activity;
- Membership of recognized professional engineering institution/association;
- Maintained continued professional development since graduation at a satisfactory level;
- At least three sponsors, who are either Fellows of IEI/Fellows of any other recognized professional engineering institutions, must support any application for PE.
- Passed the Assessment Examination as prescribed.
So, it is obvious that a certain level of skill in learning, using and applying technology, sharing knowledge so others can learn from your experience is critical to our careers, to the work we put out into the world, and our reputations as professional and skilled craftsmen.
Since the Great Democratization of the Software Industry maybe 30 years ago, we are seeing much more young people taking up Engineering, and it is a challenge to skill people at the necessary levels of competence.
SCRUM or Agile development is a very good way of dealing with this situation. Waterfall model of development is good for skilled people, already having a significant body of experience in their technology and domain, to predict things to be done for a project well in advance, before starting work. For today’s teams, where most of the members are young, domain knowledge isn’t a given, there are multi-disciplinary skill-sets, it is imperative to build things as you go. A curious mind, asking questions and learning quickly and adapting the learning to the situation is a valuable mind!
Of course, how long should things continue such (in the SCRUM way) is another topic altogether. Old-timers are right in their frustration when someone leaving the team carries away the knowledge, and things have to start all over again. “It was better when people didn’t switch jobs so often!” or “We know this takes this long, why reinvent the wheel?”
There are valid reasons to work longer in places. Within 2-3 years, a person just has got a good hand of the product he is working on, he has started understanding the domain, he can now start giving back with this knowledge. Moving to another job at this stage only means you always are in ‘learner mode’. A stable, reliable product cannot be built by halfhearted individuals, always sitting on the fence. Only a person who works longer, can understand the critical code-base of the product, and make intelligent decisions about the changes in the product. Then is it a surprise, that the core development teams in any product company are invariably highly paid?
Another common example I like to talk about is this. Civil engineers don’t build a bridge, pass an increasing amount of trucks over it, wait for it to break and say, “Hah! Let’s make it stronger than before!” There are well understood principles of construction, materials are researched, and then accepted for use.
Software Industry still is in it’s nascent stage, and the demand for skilled people is exploding. Technology, and software, is taking up its place not just in items of convenience, but replacing some decision-making. How this software is written is becoming more and more critical. Just as engineers have accountability for designing bridges that sustain storms, earthquakes, software engineers have more and more accountability in designing reliable systems. A professional mindset starts with thinking about problems, evaluating solutions, anticipating user scenarios, and developing skills that match and exceed the problem state.
SCRUM forces us to break down problems in manageable chunks, predict things for shorter durations, and practice and tune the ‘thinking ahead’ mindset. To develop this, how you read, how much of it do you understand, how do you use it and practice it, becomes important. Scott Young also put out a variant of the same thought recently in his post: How Much Do You Really Understand?
While there is certainly merit in doing things, making mistakes and learning from them, I am quite sure that spending some time thinking of things before-hand can help in avoiding some of the mistakes that you would eventually end up making. I am reminded of Thomas Edison’s famous quote: “I have not failed, I have just found 10,000 ways that won’t work. “Well, the other genius, Nikola Tesla – who argued against Thomas Edison in the famous War of the Currents – had this to say about him, “If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw after straw until he found the object of his search… I was a sorry witness of such doings, knowing that a little theory and calculation would have saved him ninety per cent of his labor.”
Engineering was always about disciplined thinking, disciplined action, regular learning.
Engineers who understand what is built, how it is built and why it is built that way are those who carry the ability of bringing dreams and visions to life! And in that, it becomes a noble profession!