I agree with Seth Godin that Being professional means making measurements.
I think at the very minimum basic code coverage metrics should be captured and tracked. Can it be claimed that a function is "done" without it having been tested? Can it be said to have been tested without the basic code coverage metrics having been recorded? Accepting a function to be "done" without even the basic code coverage metrics is being Naive.
Software is of value to the business entity that owns it. It is a business asset. Assets need to be maintained. Complex code is error prone and hard to maintain. Accepting that a function is maintainable without measuring Cyclomatic Complexity is being Naive.
Making, and accepting, schedules without having past performance metrics is being Naive.
Showing posts with label Software Talent. Show all posts
Showing posts with label Software Talent. Show all posts
28 January 2017
10 January 2014
Movies & Temping
Consider movies. The big studios employed actor, directors, story writers, ... Even owned theaters. The days of the big production studios, whether in Bollywood, or Hollywood, are long over. Earlier directors and actors signed on with a studio. Now they sign on for a movie. They refer to them as projects. They are temps. The big studios have been replaced by a movie-making ecosystem
Consider credit lists. Movies these days have credit lists at the end of the film. And they run for miles. I do not recall earlier movies having credit lists at the end of the movie. I suppose it is a result of the new model of movie making. Temps require to get credit for their work. They need to be acknowledged as having been part of the project.
The same I believe is happening in software. No, neither Infosys, nor TCS, nor ... are going to disappear any time soon. But they will increasingly resort to temping (I believe some of them already do). Their margins are going to get squeezed. They just will not be able to afford talent sitting on the bench.
My advice to those preparing for a career in software: forget it, there is no career. But there is a profession.
Networking does not mean partying. It means making other professionally more than superficially aware of your skills; and being more than superficially aware of other professionals' skills. It means getting to know other professionals, professionally.
Be very prudent with your personal finances. Avoid the debt trap. The days of the regular pay-check, for years and years, is over; so are the days of regular increments - be prepared for decrements.
Try and acquire some marketing & sales skills and communication skills. You are a marketing and sales person. The product you are marketing, and selling, is YOU. And be ready to modify the product.
Consider credit lists. Movies these days have credit lists at the end of the film. And they run for miles. I do not recall earlier movies having credit lists at the end of the movie. I suppose it is a result of the new model of movie making. Temps require to get credit for their work. They need to be acknowledged as having been part of the project.
The same I believe is happening in software. No, neither Infosys, nor TCS, nor ... are going to disappear any time soon. But they will increasingly resort to temping (I believe some of them already do). Their margins are going to get squeezed. They just will not be able to afford talent sitting on the bench.
My advice to those preparing for a career in software: forget it, there is no career. But there is a profession.
Networking does not mean partying. It means making other professionally more than superficially aware of your skills; and being more than superficially aware of other professionals' skills. It means getting to know other professionals, professionally.
Be very prudent with your personal finances. Avoid the debt trap. The days of the regular pay-check, for years and years, is over; so are the days of regular increments - be prepared for decrements.
Try and acquire some marketing & sales skills and communication skills. You are a marketing and sales person. The product you are marketing, and selling, is YOU. And be ready to modify the product.
17 July 2011
Japanese Industrial Culture & Software
A decade ago Mr. Yuasa, a customer of acmet's, asked me, 'How is it that India is so good at software". My short answer to him was, "Because we are not good at anything else!" My reply was not entirely in jest.
This was my thesis, progressively strengthened over the years:
1. The large semiconductor companies that we dealt with did not value software tools (acmet developed and maintained compilers for them).
2. They made their money selling processors. Tools and their maintenance they gave away free to support sales. It was a pure cost that, if not made zero, had to be minimized. (In a way that helped us, as otherwise they would never have outsourced tool development.)
3. The top decision makers had made their careers and reputations developing, manufacturing and selling chips - drams, processors, ... The semiconductor companies had software talent but I doubt if they really had the respect of top-management.
4. Unlike what some of my colleagues believed, Japanese software talent was strong. Evidence of that was their dominance in games and in robotics.
The Jul 16th - 22nd 2011 issue of The Economist has an article titled, "Samurai go soft", with the subtitle, "Japan's preference for hardware over software is fading". Here are some quotes:
In 2008, I remember, a large Japanese conglomerate was interested in investing in acmet. But then the financial melt-down happened. The rest, as they say, is history :-(
This was my thesis, progressively strengthened over the years:
1. The large semiconductor companies that we dealt with did not value software tools (acmet developed and maintained compilers for them).
2. They made their money selling processors. Tools and their maintenance they gave away free to support sales. It was a pure cost that, if not made zero, had to be minimized. (In a way that helped us, as otherwise they would never have outsourced tool development.)
3. The top decision makers had made their careers and reputations developing, manufacturing and selling chips - drams, processors, ... The semiconductor companies had software talent but I doubt if they really had the respect of top-management.
4. Unlike what some of my colleagues believed, Japanese software talent was strong. Evidence of that was their dominance in games and in robotics.
The Jul 16th - 22nd 2011 issue of The Economist has an article titled, "Samurai go soft", with the subtitle, "Japan's preference for hardware over software is fading". Here are some quotes:
"A samurai would never write software!" barked a senior executive at one of Japan's biggest electronics firms, ....
.. by bundling programs with machines, they taught customers that software was of little value.The article mentions that, among others, "Hitachi and Toshiba are hunting for software firms". I wish this had happened earlier - or acmet were still around.
In 2008, I remember, a large Japanese conglomerate was interested in investing in acmet. But then the financial melt-down happened. The rest, as they say, is history :-(
08 November 2010
Leadership
Seth Godin says, "It requires education and coaching and patience to create a team ..." in this post. Exactly the same as teaching sparrows.
08 September 2010
Teach Sparrows
I find it mentioned quite often that one must have great/good programmers.
Maybe in the US, with an educational system that allows for a great deal of flexibilty, with more opportunities to play around with computers at a very young age, with electronic hardware being a smaller fraction of the average household income (as compared to India), it may be possible to determine proggrammer suitability at induction.
Most Indian looking to become software professionals have not had these advantages. So looking for great programmers is not a viable course of action. What we have to look for is the desire to prove oneself; the fire in the belly. That was a belief of my late friend, and boss, RR (the late Wg Cdr R Raghavan). I do not remember him to have ever asked a single technical question of any inductee.
Many of the people whom we took in at acmet (and earlier at Ergo) could not make campus placement. I am sure I am not wrong when I say that, today, all are with the some of the best brands in the business of electronics and software. They had the desire to prove themselves acmet (and earlier Ergo) provided the opportunity.
Guru Gobind Singh, the tenth guru of the Sikhs, said, ""I will teach the sparrow to hunt the hawk" .(quoted from Khushwant Singh's article).
My friend RR taught sparrows.
Maybe in the US, with an educational system that allows for a great deal of flexibilty, with more opportunities to play around with computers at a very young age, with electronic hardware being a smaller fraction of the average household income (as compared to India), it may be possible to determine proggrammer suitability at induction.
Most Indian looking to become software professionals have not had these advantages. So looking for great programmers is not a viable course of action. What we have to look for is the desire to prove oneself; the fire in the belly. That was a belief of my late friend, and boss, RR (the late Wg Cdr R Raghavan). I do not remember him to have ever asked a single technical question of any inductee.
Many of the people whom we took in at acmet (and earlier at Ergo) could not make campus placement. I am sure I am not wrong when I say that, today, all are with the some of the best brands in the business of electronics and software. They had the desire to prove themselves acmet (and earlier Ergo) provided the opportunity.
Guru Gobind Singh, the tenth guru of the Sikhs, said, ""I will teach the sparrow to hunt the hawk" .(quoted from Khushwant Singh's article).
My friend RR taught sparrows.
06 September 2010
Who Makes Product Specs?
Paul Graham in his essay on what happened to Yahoo says:
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
12 May 2010
Talent & Quality of Software Deliverables - 2
How does one recognize talent?
The first step is to be aware of what talents you require. In my previous post I had identified talents I wanted for the programming tools business unit. I had also mentioned what was expected of specific talents. The way I did it was to work from the process practices that we needed to adopt. (I shall post these practices in a later post.). The process practices were in turn based on our business reality. What was our business reality? It was defined by:
To identify talents at the entry level it helps to have an internship program. The longer the internship, the better the chances of determining if the required talents are present. MCA programs require a final semester of industrial experience. That is a very good opportunity to check for the talents I have listed in the earlier post.
The normal interview process does not have enough time for determining talents. However, for companies that can afford them, hiring qualified psychologists as consultants to test for the required talents, could be an option.
In either case it is absolutely important for managers to continually monitor the performance of all their team members. They must see that required talents are indeed being displayed. If any previously unspotted talent is noticed, it must be discussed with the person. All should be provided feedback. I believe in highlighting both desirable and undesirable behaviour to the whole team. And as close to the episode as possible. That way everyone learns what is the expected behaviour.
Most importantly, the annual (at acmet it was bi-annual) assessment must be designed to evaluate the behaviours which are evidence of the desired talents. At acmet our assessment forms did that.
The first step is to be aware of what talents you require. In my previous post I had identified talents I wanted for the programming tools business unit. I had also mentioned what was expected of specific talents. The way I did it was to work from the process practices that we needed to adopt. (I shall post these practices in a later post.). The process practices were in turn based on our business reality. What was our business reality? It was defined by:
- Programming tools have a long life. These required to be maintained over many generations of developers. In the tools BU Maintenance is Renovation.
- Optimizing compilers are complex. Complexity leads to difficulty in maintaining them.
- Turnover of personnel.
To identify talents at the entry level it helps to have an internship program. The longer the internship, the better the chances of determining if the required talents are present. MCA programs require a final semester of industrial experience. That is a very good opportunity to check for the talents I have listed in the earlier post.
The normal interview process does not have enough time for determining talents. However, for companies that can afford them, hiring qualified psychologists as consultants to test for the required talents, could be an option.
In either case it is absolutely important for managers to continually monitor the performance of all their team members. They must see that required talents are indeed being displayed. If any previously unspotted talent is noticed, it must be discussed with the person. All should be provided feedback. I believe in highlighting both desirable and undesirable behaviour to the whole team. And as close to the episode as possible. That way everyone learns what is the expected behaviour.
Most importantly, the annual (at acmet it was bi-annual) assessment must be designed to evaluate the behaviours which are evidence of the desired talents. At acmet our assessment forms did that.
06 May 2010
Talent & Quality of Software Deliverables - 1
In Apenndix C of their book, First, Break All the Rules: What the World's Greatest Managers Do Differently, the authors briefly describe the talents that are found most frequently across all roles. They classify them as Striving Talents, Thinking Talents, and Relating Talents.Striving talents are what drives a person. Thinking talents are thinking patterns, frameworks, view points, which come naturally to a person. Relating talents are how a person engages with others.
For entry level for business unit that I headed, the talents that I would look for are:
Striving Talent
- Ethics: Total honesty about work done.
- Belief: In the values of the organization
- Service: A readiness to put team before self
- Acheiver: A drive to meet commitments.
- Competition: This is a no-no. See relating talents
- Discipline: Structure in planning and executing commitments, and in writing code
- Focus: On meeting commitments and not getting diverted by interesting side issues.
- Problem Solving: Construct experiments to learn about problems. Devise tests to validate unserstanding. Recognize patterns.
- Team: Be a team player. Support others. Be ready to take on extra work to help out others going through a difficult patch.
- Empathy: Be sensitive to feelings of others. Review comments should not be personal. Information should not be delivered in a manner that seeks to run down others.
- Persuasion: Use logic - not prejudice, nor authority, nor politics - to convince team members during reviews of project artefacts.
- Developer: Educate new members of the team. Share information. Involve less experienced persons in the discussion and explain the discussion. Help others learn. Do not form cliques. Document code and tests so that future team members can learn.
- Multirelator: Build relations that are not based on langauage, region, caste, or political affliation.
My experience had convinced me some time ago of the kind of person we should be selecting for the business unit that I headed. I have linked that to the some of the talents mentioned in the appendix of the book. I wish I had read the book a few years back. It would have enabled me to craft a better selection, assessment and retention scheme.
So how does one identify the talents that I have mentioned? I propose to deal with that in the next post.
Subscribe to:
Posts (Atom)