Interesting discussion about IT industry @ SRB

[Stanly Lau]

There is an interesting discussion recently at Singapore Ruby Brigade (a Ruby User Group) about IT industry in Singapore from different perspectives. It started as a hiring post but turned into a discussion of developer to manager assumptions, pay-scale, myths, IT industry in Singapore and how to support developers to learn.

Here is the link to their Google Groups. (Warning, long thread)

Stanly

[Maysam]

cannot see the link

[Bas Vodde]

Was an html href.

Plain text is at:
https://groups.google.com/forum/#!topic/singapore-rb/QsaJ-K5mQu4/discussion

Bas

[Duncan Campbell]

(Catching up on e-mail while my other laptop is frozen whilst updating...)

Thanks for the link.  It confirms the anecdotes I'd heard previously about the attitudes to software development in Singapore, and how it appears to be a regional attitude.

(Interesting how "Management" was equated with "Project Management"...)

Duncan

[James Chua]

the group title is agile so is already moving to managment.

---

Date: Wed, 4 Apr 2012 09:45:30 +0800
Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB
From: duncan.su...@googlemail.com
To: agilesi...@googlegroups.com

[Bas Vodde]

Hiya James,

I'm afraid I don't understand what you are saying. Could you clarify the meaning?

Thanks!

Bas

On 04-Apr-2012, at 11:30 AM, James Chua wrote:

> the group title is agile so is already moving to managment.
>

[James Chua]

Just wish to point out agile way is kind of a management topic.

> Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB

> From: ba...@odd-e.com
> Date: Wed, 4 Apr 2012 11:34:39 +0800
> To: agilesi...@googlegroups.com

[Steve Clancy]

Hi James, you mean that Agile is more than just a collection of engineering practices. It is also an approach to organising social structures as well as the requirements and temporal dimension. Agile encapsulates all of these?

So just as it should not be mandatory to move out of development and this should be a valid career path, equally to really penetrate into an organisation the ideas of agile need to be championed up thru management. Including first project management then more senior management. People should follow their aptitude and ambition else they will never be content.

Rgds  Steve 

Sent from my iPhone

[James Chua]

it may be inevitable that management path is required for the same reasons that A team football players have short expiry dates

---

CC: agilesi...@googlegroups.com
From: klan...@gmail.com

Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB

Date: Wed, 4 Apr 2012 12:29:37 +0800
To: agilesi...@googlegroups.com

[Duncan Campbell]

That's right, these new kids come along with their nibble fingers and can bash out 100wpm, while my rheumatic fat fingers can barely knock 10wpm.

Coding's a young person's game for sure...

So, the only thing left for me to do was to sit in a big chair and occasionally say things like "When I was your age we didn't have any of these fancy IDEs, etc....."

2012/4/4 James Chua <bigtreee...@hotmail.com>

[Bas Vodde]

Hi James,

Are you saying that developers can't stay developers for life?

I'm a bit unclear about your comments still :)

Bas

On 04-Apr-2012, at 1:23 PM, James Chua wrote:

> it may be inevitable that management path is required for the same reasons that A team football players have short expiry dates
>

[Kevin Yeung]

Just my anecdotal 2c.

Most organisations I know equate management with project management, because the project manager is put in charge to deliver the product/project with "resources" and power given. These resources have to seek approval from the PM for leave and training. If you have a sick child at home and need to leave work early it's the PM you ask for forgiveness. Performance targets are set early in the year and evaluated at year end by the same PM. Salary increment, bonus and promotion are entirely up to the PM to decide, usually as a function of how obedient you have been for staying late or taking up extra duties. Quality and innovation are usually not taken into consideration in the traditional SDLC setup because testing isn't done until very late if at all and even then by a separate team. In other words the PM does not only dictate how much you earn now but also how much you earn in the future. When the team have to decide on conflicting technical choices it's often the PM who has the final say on the premise that there's a fixed delivery date so it's a project management decision. There's often an adult-child relationship in IT.

In other words, a project manager in an SDLC project is vested with enormous power. Can we blame the wild-eyed newbies for wanting to become management?

I have never gone around asking how much everyone earns but I'd hazard that if you're 3 years into programming you'll be earning substantially less than the PM who's been entrusted with a half-million dollar project. I'd further hazard that unless you're actively taking care of your career and learning new, strategic and valuable skills (no, mastering database indexing algorithm isn't one of them) by the time you reach 6-8 years in your programming career you'll still be bossed around in your early 30's, still staying back late because of production issues, still staring at a meager $200 salary increment that hardly beats inflation - not a winning formula for most devs.

And for many people getting out means being a manager because they've got a CS degree and that's how they know to make a living.

Some have pointed out that a PM has no real control over whether a project delivers or slips but remember a dev's life is even worse. It's either black or white. Either your code is tested and checked in or it is not. A project manager can often cite a myriad of reasons for slips (eg, external vendors, Ops, scope creep, the programmers!). Programmers don't get paid overtime in Singapore so when there's a scope creep or a huge quality gap programmers are left on their own to fend for themselves with no compensation. The PM? Home with his kids. Now I can see someone in the audience getting ready to fire but like I said it's anecdotal so YMMV. Which is why middle managers are often the obstacles in any agile transformation because their vested powers are being taken away.

I see the way to change is programmers getting more educated, more technical, more strategic, and aligning the hypothetical PM's interests with theirs. Better still, become a heretical PM and build an agile team yourself. It's not easy holding out being purely technical past the 10th year. Of course there're enclaves here and there but they're hard to sniff out.

Or maybe I'm just pessimistic and wrong...? How I wish I am wrong this time. Someone tell me I'm wrong.

---

From: Duncan Campbell <duncan.su...@googlemail.com>
To: agilesi...@googlegroups.com
Sent: Wednesday, 4 April 2012, 9:45

Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB

[Bas Vodde]

Hi Kevin,

I think you are wrong :)

That is, I think you are right about how things are now, but wrong about how things can (and hopefully will be). What you see in the world is that technology knowledge is becoming more and more the core of many businesses. The people who I believe are the future are the people who can understand how a business work and how the technology works (because they are still hands-on with technology). I don't believe project management or most management has any future and I would consider it very short-sighted to jump into a management position in an organization. Why? Most modern management techniques (Scrum included) promote self-management, more empowerment and flatter organizations. Companies who keep their traditional hierarchies (like most Singaporean companies) simply won't be able to compete with companies who break them and get the most out of their employees. You see that already in the world with companies such as Google, Facebook. It is just that Singapore is about 10 years behind in thinking than the rest of the world, which is very sad :(

Our company (Odd-e) is still small (10 people) but is structured in a way where there is no management and no hierarchy and it won't ever exist. I personally believe that that kind of structure is more human, leads to more satisfaction, and leads to more productive companies that will be the companies of the future.

So, you are wrong :)

Bas

On 04-Apr-2012, at 4:11 PM, Kevin Yeung wrote:

> Just my anecdotal 2c.
>
> Most organisations I know equate management with project management, because the project manager is put in charge to deliver the product/project with "resources" and power given. These resources have to seek approval from the PM for leave and training. If you have a sick child at home and need to leave work early it's the PM you ask for forgiveness. Performance targets are set early in the year and evaluated at year end by the same PM. Salary increment, bonus and promotion are entirely up to the PM to decide, usually as a function of how obedient you have been for staying late or taking up extra duties. Quality and innovation are usually not taken into consideration in the traditional SDLC setup because testing isn't done until very late if at all and even then by a separate team. In other words the PM does not only dictate how much you earn now but also how much you earn in the future. When the team have to decide on conflicting technical choices it's often the PM who has the final say on the premise that there's a fixed delivery date so it's a project management decision. There's often an adult-child relationship in IT.
>
> In other words, a project manager in an SDLC project is vested with enormous power. Can we blame the wild-eyed newbies for wanting to become management?
>
> I have never gone around asking how much everyone earns but I'd hazard that if you're 3 years into programming you'll be earning substantially less than the PM who's been entrusted with a half-million dollar project. I'd further hazard that unless you're actively taking care of your career and learning new, strategic and valuable skills (no, mastering database indexing algorithm isn't one of them) by the time you reach 6-8 years in your programming career you'll still be bossed around in your early 30's, still staying back late because of production issues, still staring at a meager $200 salary increment that hardly beats inflation - not a winning formula for most devs.
>
> And for many people getting out means being a manager because they've got a CS degree and that's how they know to make a living.
>
> Some have pointed out that a PM has no real control over whether a project delivers or slips but remember a dev's life is even worse. It's either black or white. Either your code is tested and checked in or it is not. A project manager can often cite a myriad of reasons for slips (eg, external vendors, Ops, scope creep, the programmers!). Programmers don't get paid overtime in Singapore so when there's a scope creep or a huge quality gap programmers are left on their own to fend for themselves with no compensation. The PM? Home with his kids. Now I can see someone in the audience getting ready to fire but like I said it's anecdotal so YMMV. Which is why middle managers are often the obstacles in any agile transformation because their vested powers are being taken away.
>
> I see the way to change is programmers getting more educated, more technical, more strategic, and aligning the hypothetical PM's interests with theirs. Better still, become a heretical PM and build an agile team yourself. It's not easy holding out being purely technical past the 10th year. Of course there're enclaves here and there but they're hard to sniff out.
>
> Or maybe I'm just pessimistic and wrong...? How I wish I am wrong this time. Someone tell me I'm wrong.
>

[Ruslan Khafizov]

On Wed, Apr 4, 2012 at 4:19 PM, Bas Vodde <ba...@odd-e.com> wrote:

Companies who keep their traditional hierarchies (like most Singaporean companies) simply won't be able to compete with companies who break them and get the most out of their employees. You see that already in the world with companies such as Google, Facebook.

I have doubt incumbents will go out of business any time soon. Whom did google put out of business? As far as I can see google and facebook compete only with each other :-)

Even companies close to technology, say mobile. If you seen their booth at a mall you notice it's full of people.

Then I just came to Singapore I was wondering what all people do there but soon it was time to take a subscription and I realized you can hardly do anything online. So I had to go and take a queue :-)

It's possible to make it better but how you would challenge telecom operator? They shared the market and quite comfy at their equilibrium without any initiative to improve. So I doubt they will change their structure any time soon.

And this situation is everywhere: behemoths, market without competition, no initiative to improve.

Things are getting better but very slowly. So most of current middle managers will be able retire.

But those who are in their 20s probably not :-)

Regards,

Ruslan

[Bas Vodde]

Hi Ruslan,

Yah, I didn't mean... well.. tomorrow everything will be changed. But the trend is towards change in flatter organizations and more tech focused. As a middle manager, I would still worry :)

I do think Google put companies out of business, but the traditional example is, of course, amazon.com having bankrupted Borders... and all the Singapore computer book stores (which was our previous thread).

Having worked in telecom industry for years... that world is actually constantly being shaken up. This is mainly because there is a movement from hardware to software and a movement towards IP-based IETF open standards. That means, nearly everyone can enter that market over time. You see that with the vendor companies who are in trouble because their in-efficiency is pushing them in a smaller and smaller market (innovators dillema at work).

Companies like Singtel and Starhub still make a lot of profit on e.g. roaming, whereas those are likely to disappear in the future when more IP-based telephony.

Again, it won't happen tomorrow, but I would be worried as a middle manager :P

Bas

[Steve Clancy]

Hi Bas,

In a similar vein I think you are right when looking from one perspective but wrong from another.

Management as we know it will be changed, and if agile and lean approaches are worth their salt then
those that adopt will thrive and those that do not, will slowly fall behind.

In a small organisation it may appear that you each have simple roles, however I would imagine that you
have an accountant, a lawyer, a landlord, a bank (an business banker), a logistics manager, a procurement
manager, financial controller, HR, payroll, ...even cleaner....etc ...??
Someone is managing or undertaking these roles - even if it is in a self organising team approach.

They may not be visible but "management", it is, only some of the people are wearing multiple hats.
But even if it is a self-organising team that deceides - a decision must be taken.
As an organisation scales, coordination across teams will need to be implemented in some form
(scrum-of-scrum-of-scrum is one option) or else value will be lost.

So size does matter, management (in the enlighten sense - agile/lean) should not be a dirty word and it requires talented
and experienced people. I agree the best value management, like code, is that which is not there (remove waste).
But "mangement" does provide value when it is just enough.

Cheers

Steve

This email has been refactored and is all MHO.

[Kevin Yeung]

Hi Bas

Thanks for taking the time to read through my long-winded post.

I've stated the status quo but by no means do I agree to it or think it's justifiable. If you read my closing you'd notice I am advocating 

1. programmers getting more educated thereby empowering themselves to better align with the PM's goal, ie, delivering the project. My experience has been that that helps me see where the inefficiencies and wastes are. By optimising away those wastes it improves one's standing and also naturally make the team more agile. That works for the short term.

2. mid- to long-term, if you find yourself employed in a traditional hierarchy then why not become a manager of some kind and do the transformation with more power and influence? I don't think holding a manager title automatically turns one to the dark side. It's what you do with the power that comes with it. I'm against newly-minted managers perpetuating the vicious cycle. I am not against someone "making management", to use the original phrase, and using that power to spread the agile/respect gospel. That's my heretical PM. :)

3. Those companies you cited, and Odd-e, are the enclaves. Not everyone works there unfortunately.

I'm not sure I've put forth my mini-rant coherently but it's been a constant struggle for me to stay technical without suffering too much from it. Through dumb luck and meeting the right people at the right time I've escaped largely unscathed. :)

YMMV

Kevin

---

From: Bas Vodde <ba...@odd-e.com>
To: agilesi...@googlegroups.com
Sent: Wednesday, 4 April 2012, 16:19

[Duncan Campbell]

All this sounds like a couple of very old and established organisational models: the cooperative and the collective.

[Duncan Campbell]

Your description of programmers increasing their education and value to the organisation sounds very much like them becoming engineers, software engineers, rather than technicians, and in so doing acting like engineers and being treated as engineers rather than technicians.

Duncan Campbell CEng MBCS CITP MIET

[Bas Vodde]

Hi Steve,

Well... :) I don't believe I said "management" is a dirty word. Also, reading your email, I think we'll need to differentiate between management the verb and management the noun (as in a collection of managers).

Management the verb will always be needed and there isn't anything "bad" about it. In self-managing teams, there is a lot of management going on even though there are no managers (the noun). Management (verb) doesn't have to be done by management (noun)...

Also, I didn't say that all organizations in the future will have no management (noun). I don't think that will happen anytime soon. Yet, I don't think that management (noun) is the way "up the organization" in the future as the value of people with technical/domain skills will be increasing whereas the amount of management (noun) will decrease as management (verb) will be pushed down the organization to create more empowerment and flexibility.

A great example is a telecom product I worked with for years. The chief architect (who writes code!!!) salary is quite a lot more than the "head of development", who is a 4th level manager in that organization. Why? Well the chief architect is considered way more important as the product sort-of depends on his knowledge and experience, whereas the "head of development" is ... well.. just another manager.

Right now, this is an exception to the rule, but I think it will be more and more common in the future as people realize that it is usually not managers who have the core skills in the organization, but the people who actually make the products :)

Oh, related to Odd-e, we don't have support functions such as HR, payroll, logistics etc as within our structure those roles aren't "allowed" by the way the organization works. We do have "accountant" but that is outsourced as the company is structured explicitly without supporting functions. That said, we're still relatively small, but have no plan to change it ever :)

Bas

[Bas Vodde]

Hi Kevin,

> Thanks for taking the time to read through my long-winded post.
>
> I've stated the status quo but by no means do I agree to it or think it's justifiable. If you read my closing you'd notice I am advocating
>
> 1. programmers getting more educated thereby empowering themselves to better align with the PM's goal, ie, delivering the project. My experience has been that that helps me see where the inefficiencies and wastes are. By optimising away those wastes it improves one's standing and also naturally make the team more agile. That works for the short term.

Well, when adopting Scrum, you shouldn't have any PMs in your organization as the essence of Scrum is to distribute PM over different roles and give most of the project management responsibilities to the Team itself. In good organizations that have adopted Scrum (even large ones) I've seen that happen where the PM role disappears.

So, programmers getting more educated isn't enough :) Project managers ought to realize that for SW development, managing in a backwards scientific management style (like PMI/PMP) isn't working not efficient in the area of knowledge workers.

> 2. mid- to long-term, if you find yourself employed in a traditional hierarchy then why not become a manager of some kind and do the transformation with more power and influence? I don't think holding a manager title automatically turns one to the dark side. It's what you do with the power that comes with it. I'm against newly-minted managers perpetuating the vicious cycle. I am not against someone "making management", to use the original phrase, and using that power to spread the agile/respect gospel. That's my heretical PM. :)

I'd recommend most people to *not* become a manager as I see it as an excellent way to ruin your career. For most managers that I meet, they completely lost their value-added competence and their main competence is how to manuevre in their organization and how to play organizational politics. That means that your competence is purely limited to the organization in which you work. In 2012, that isn't a very smart thing to do as (unfortunately) most companies don't give a sh*t about their employees and they outsource/offshore your job (and the management jobs) without blinking twice and then you are on the street with no useful skill whatsoever.

I know quite a lot of people who became managers in a large company, after which they got laid off because the organization wasn't doing well, and they ended up in a lot poorer job than they had before. I think this will be very very common in Singapore in the future because I consider it inevitable that organizations become flatter and thus the current middle managers will... need to actually learn a useful skill :)

Staying purely technical is also a dead end. It is probably even worst because then you admit that you are just another cog in the larger machine that is controlled by "the more powerful" and you are just a... well.. programmer. That makes no sense.

As I mentioned in the previous mail, I think the people who are going to be the most valuable are the ones who are hands on technical AND have a good understanding of how the business works. It isn't a purely technical person because he understands why he builds what he builds and how it works within the company. I see more and more people like these developing themselves and I think they are the future of organizations as they are able to remove silo thinking and actually deliver more value to customers, faster.

> 3. Those companies you cited, and Odd-e, are the enclaves. Not everyone works there unfortunately.

Yes, maybe. But I think the amount of "those companies" will rapidly grow in the world and their importance even more rapidly.

> I'm not sure I've put forth my mini-rant coherently but it's been a constant struggle for me to stay technical without suffering too much from it. Through dumb luck and meeting the right people at the right time I've escaped largely unscathed. :)

I think staying technical will pay off in the end :) As long as you update your knowledge constantly.

Bas

>
> YMMV
>
> Kevin

[Duncan Campbell]

Bas,

What you're describing sounds very traditional - traditional for the traditional professions, where the "practitioner-manager" is commonplace.

The technical worker and non-technical manager is also very traditional - traditional in a factory, which is why Fred Taylor came up with his scientific management so that managers could then control what the workers did, rather than the artisan workers having full control over their working practices and the managers knowing nothing about how things were done.  (Cue the jokes...)

So, we are in agreement that software development needs to move from the factory floor to the professional's office - though in Marxism there's little difference as you are still workers rather than owning the means of production.

In the UK at least over the last few decades there has been a move away from practitioner managers to professional administrators, particularly in the fields of education and healthcare, and even in railways - this is something I see as a bad thing.

Practitioner managers (and practitioner leaders) mean that the leadership can provide direction with regard to the profession or practice rather than (just) the balance sheet.



Software developers of the world unite! ...and act like professionals.

[James Chua]

being professionals can be just a cover to set up a monopoly and charged ultra high price.

Lawyers , doctors and accountants operate under that mode.

---

Date: Thu, 5 Apr 2012 12:18:30 +0800

Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB

From: duncan.su...@googlemail.com
To: agilesi...@googlegroups.com

[Bas Vodde]

Hi Duncun,

> In the UK at least over the last few decades there has been a move away from practitioner managers to professional administrators, particularly in the fields of education and healthcare, and even in railways - this is something I see as a bad thing.

Yes, I think the "professional manager" is an illusion. And you see that a lot in our industry when companies started by engineers are taken over my marketing or accountants who practice "professional management" then the company is doomed to fail. Stanly today send me an article on Steve Jobs in which he stressed exactly this point:
hbr.org/2012/04/the-real-leadership-lessons-of-steve-jobs/ar/1

To quote:

"John Sculley, who ran Apple from 1983 to 1993, was a marketing and sales executive from Pepsi. He focused more on profit maximization than on product design after Jobs left, and Apple gradually declined. “I have my own theory about why decline happens at companies,” Jobs told me: They make some great products, but then the sales and marketing people take over the company, because they are the ones who can juice up profits. “When the sales guys run the company, the product guys don’t matter so much, and a lot of them just turn off. It happened at Apple when Sculley came in, which was my fault, and it happened when Ballmer took over at Microsoft.”"

> Practitioner managers (and practitioner leaders) mean that the leadership can provide direction with regard to the profession or practice rather than (just) the balance sheet.

Yes.

> Software developers of the world unite! ...and act like professionals.

Yes :)

Bas

[Bas Vodde]

Hi James,

> being professionals can be just a cover to set up a monopoly and charged ultra high price.

I actually think it is fair for a good developer to charge a "ultra high price". This is exactly what is wrong in our industry. We do as if you can replace one developer with another easily, but anyone involved in development knows that is a pure illusion. The difference in output and work of different developers is huge and that warrants a high price.

> Lawyers , doctors and accountants operate under that mode.

Yes, people who are good will be able to charge higher fees. Especially a lot higher than dummy middle managers :)

Bas

[Edwardcher Monreal]

Sorry guys, can't help but drop in. Dreyfus Model anyone? Just taking another pragmatic perspective. For those who haven't heard about it (and are patient enough to read through) you can check out http://media.pragprog.com/titles/ahptl/chap2.pdf. Interestingly, section 2.4 is cut out which somehow paraphrases most if this threads discussion (so for those who have the book feel free to revisit the chapter). For those not so patient, you can view a video about "Herding Race Horses and Racing Sheep" by Dave Thomas here http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas  

Again interesting topic all with valid points

> Practitioner managers (and practitioner leaders) mean that the leadership can provide direction with regard to the profession or practice rather than (just) the balance sheet.
>

> Duncan

I agree.

> I think staying technical will pay off in the end :) As long as you update your knowledge constantly.
>
> Bas

I fully agree.

Edward

[Ruslan Khafizov]

Hi Bas,

On Thu, Apr 5, 2012 at 11:52 AM, Bas Vodde <ba...@odd-e.com> wrote:

As I mentioned in the previous mail, I think the people who are going to be the most valuable are the ones who are hands on technical AND have a good understanding of how the business works. It isn't a purely technical person because he understands why he builds what he builds and how it works within the company. I see more and more people like these developing themselves and I think they are the future of organizations as they are able to remove silo thinking and actually deliver more value to customers, faster.

 

There's a catch here as well - you lock yourself to domain. If you spend 10 years in domain everyone will see you as a domain developer. It's better than a MM as you have pure technical skills but still tough.

Regards,

Ruslan

[Panwei Ng]

Hi,

 

I also can’t help but drop in. Thanks Edward for the reference to the Dreyfous Model with the 5 levels:

(1)    Novice who needs recipes and step by step guidance,

(2)    Advance Beginners who still cannot comprehend the big picture yet

(3)    Competent people who take the initiative and are resourceful

(4)    Proficient folks who can self-correct.

(5)    Expert who can work on intuition.

It is a short chapter and can be read in 5 to 10 minutes – it is worth the time.

 

I recall Alistair Cockburn who referred to Shu-Ha-Ri of Bushido (Japanese martial arts) (see http://alistair.cockburn.us/Shu+Ha+Ri ).

(1)    Shu. When learning something, one starts with Shu (learn just one method and adhere to that method). It is important to learn just **one** method now as otherwise the novice gets very confused.

(2)    Ha – At this point, the student branches out and appreciate the difference between reality and what he knows. He learns from others how to fill the gap

(3)    Ri – At this point, the individual understand deep principles and is able to transcend methods. He can invent solutions.

 

In software teams (an organizations), we usually a mix of people at  different level of competencies in different areas. Someone might be expert in Java, but not so competent when it comes to say system/cyber security. Someone might be expert in web server/database performance tuning, but a novice when it comes to intellectual property and dealing with lawsuits.

 

It is not easy (read impossible) to learn everything and become expert in everything immediately. As such, the tendency is to have some kind of specialization. The trend today is for companies to value T-shaped people (people who are experts in a particular area, but broad knowledge in many areas) as opposed to I-shaped people (who have only knows one area). (see http://en.wikipedia.org/wiki/T-shaped_skills )

 

My opinion is as follows:

1.       Shu-Ha-Ri. It is begin with one approach, but do not be stuck in that and be too religious in that one approach/mindset. Be humble to broaden the mind. Be humble to learn from others.  

2.       Many times, no-knowledge is better that partial knowledge. There is an Arabian saying:

a.       He who knows that he knows – He is wise, follow him.

b.      He who knows not that he knows  - He is asleep, wake him

c.       He who knows that he knows not – Teach him

d.      He who knows not that he knows not – He is a fool.

3.       Each person must understand his/her core strength and value to the development team/organization. If it is expertise in code/design, good. If it is expertise in leading people, getting people to work together, inspiring people, good! If it is communicating with customer representative, having an eye for market trends/needs, excellent.  Build that core strength. But do not neglect other areas. Be that T-shaped guy, but let the T be a T with a thick stem, rather than a thin stem.

4.       Be it “managers” or “programmers”, I think it is important to be T-shaped.

5.       In an organization, there will be a mix of novice and experts. The key idea challenge is how to make the best use of the current situation, and how to bring the current situation to the next higher level, working under the constraints.

6.       Lean principles says “Go See for Yourself”. In such discussion as this, it is very hypothetical. Idealism can often be mistaken as arrogance. It is important to see what is on the ground at a specific company. Then perhaps some concrete/actionable recommendations can arise. It is good to see a lively debate here, but I do not think that it will change anyone’s opinion on things.

 

The success of a company depends on many many factors. Software development is just one of them. There are many other factors, such as customer relationship, hitting the right business model, following/leading the right trend, etc. Many times, those who make money are those who are in the right company than those with the right competencies. The right companies will often give the environment to build the right skills and grow in many areas.

 

Incidentally, amongst the people I work with, are telecom equipment providers.

1.       I know of a major telecom equipment provider (let’s call this company A) who just shut down their German operations. Everyone was let off – programmers and managers.

2.       I also know of another telecom equipment provider (let’s call this company B) had risen rapidly over that last 10 years and had put many in this field out of business. This telecom equipment provider has many managers who do not code, but a number of them recognize the value of code, and see the total value chain.

3.       Incidentally, the company A was one of the birthplace of agile development. In recent years, the agilistas from company A left company A and became agile coaches to other companies.

 

 

Cheers

-- Pan Wei

[Bas Vodde]

Hiya,

> On Thu, Apr 5, 2012 at 11:52 AM, Bas Vodde <ba...@odd-e.com> wrote:
> As I mentioned in the previous mail, I think the people who are going to be the most valuable are the ones who are hands on technical AND have a good understanding of how the business works. It isn't a purely technical person because he understands why he builds what he builds and how it works within the company. I see more and more people like these developing themselves and I think they are the future of organizations as they are able to remove silo thinking and actually deliver more value to customers, faster.
>
> There's a catch here as well - you lock yourself to domain. If you spend 10 years in domain everyone will see you as a domain developer. It's better than a MM as you have pure technical skills but still tough.

Yah, agree. Well, I didn't mean that you need to restrict yourself to one domain :) It is just that whatever domain you work in at that moment, you ought to understand it as a developer ought to understand *why* he is building the software he is building :)

Bas

>
> Regards,
> Ruslan

[Ivan]

On Thu, Apr 5, 2012 at 4:06 PM, Edwardcher Monreal
<edwardche...@gmail.com> wrote:
> Sorry guys, can't help but drop in. Dreyfus Model anyone? Just taking
> another pragmatic perspective. For those who haven't heard about it (and are
> patient enough to read through) you can check out
> http://media.pragprog.com/titles/ahptl/chap2.pdf.

The whole book is good.

- Ivan

[Ivan]

> Software developers of the world unite! ...and act like professionals.

People of the world unite!... and act like ampros :)

http://en.wikipedia.org/wiki/Amateur_professionalism
http://www.etymonline.com/index.php?term=amateur

[Duncan Campbell]

Interesting, but shouldn't there be a distinction between people being an amateur to a professional level and those professionals who perform at an amateur level...?

[Edwardcher Monreal]

Thanks Pan Wei. 

It was kind of you for listing down the Dreyfus Levels. Dreyfus helps us realize (professional) practitioners need to work on becoming Proficient to truly take advantage of Agile. 

Here's another article by Andy Hunt "10 down, A thousand to go"  http://pragprog.com/magazines/2011-02/agile--  for a Prags perspective. This is from Agile @ 10 where Ten Authors of The Agile Manifesto reflect on the Tenth Anniversary. Again I think people with enough context can relate to this more that people who's just beginning with Agile. Speaking of context here's a key note video by Andy himself at Ruby Midwest 2011  http://www.youtube.com/watch?v=IID8fD-uKSU for those who are visual/spatial and have difficulty parsing text :)

For the Shu-Ha-Ri concept:

  (1) Shu stage the student copies the master’s moves as perfectly as possible.

  (2) Ha stages he or she understands the principles well enough to depart from rigid mimicry and try different variations.

  (3) Ri the martial artist has reached a point of mastery. Her reflexes and thinking are well-formed and she requires little conscious guidance to carry out combinations of movements.

I concur in respect to the philosophical and practical application of this thinking as journeymen work towards mastering our craft which you have elaborated well enough already. There are similarities to the music profession as well.

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:  

  (1) Imitate

  (2) Assimilate

  (3) Innovate

This echoes the cycle of training in martial arts. So among other things, we need to look at ways to keep as much existing expertise as we can in the project itself; non of this progression will help if practitioners don't stay in the field. So I believe we should strive to keep expertise in practice. Thus, keep practising in order to remain expert. There's no expertise without experience, and there's no substitute for experience - but we can work to make the experience we have more efficient and more effective by becoming more aware about it given context.

- Edward 

[Duncan Campbell]

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:  

  (1) Imitate

  (2) Assimilate

  (3) Innovate

This reminds me of looking at the development of Picasso's work.  Picasso started of learning the basics: learning how to draw and paint the real world very well.  Later Picasso drew the real world as a master, capturing the profile of an object with just a single stroke of the brush or pencil.  Finallly Picasso experimented, ending up with eyes on the same side of the face, etc...

[Duncan Campbell]

On 6 April 2012 11:32, Duncan Campbell <duncan.su...@googlemail.com> wrote:

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:  

  (1) Imitate

  (2) Assimilate

  (3) Innovate

This reminds me of looking at the development of Picasso's work.  Picasso started of learning the basics: learning how to draw and paint the real world very well.  Later Picasso drew the real world as a master, capturing the profile of an object with just a single stroke of the brush or pencil.  Finallly Picasso experimented, ending up with eyes on the same side of the face, etc...

What I forgot to mention was that it was that grounding in the basics which allowed Picasso to excel at painting people with eyes on the same side of the face...

Also, take the best pop performers.  They were not kids in their bedrooms with a computer, but they were classically trained musicians who could then apply that basic training in new areas.



 

[Edwardcher Monreal]

Agree Duncan. This is why craftsmanship model sits well in our profession i.e. (1) Apprentice (2) Journeyman (3) Master Craftsman because it follows this universal pattern. 

Picasso is obviously a great example of a Master Craftsman :)     

[James Chua]

(1) Imitate

yes.  cut and paste is bread and butter in my short software programming career.

---

Date: Fri, 6 Apr 2012 11:44:56 +0800

Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB

From: edwardche...@gmail.com
To: agilesi...@googlegroups.com

Agree Duncan. This is why craftsmanship model sits well in our profession i.e. (1) Apprentice (2) Journeyman (3) Master Craftsman because it follows this universal pattern. 

Picasso is obviously a great example of a Master Craftsman :)     

On Fri, Apr 6, 2012 at 11:32 AM, Duncan Campbell <duncan.su...@googlemail.com> wrote:

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:  

  (1) Imitate

  (2) Assimilate

  (3) Innovate

This reminds me of looking at the development of Picasso's work.  Picasso started of learning the basics: learning how to draw and paint the real world very well.  Later Picasso drew the real world as a master, capturing the profile of an object with just a single stroke of the brush or pencil.  Finallly Picasso experimented, ending up with eyes on the same side of the face, etc...

On 6 April 2012 10:59, Edwardcher Monreal <edwardche...@gmail.com> wrote:

Thanks Pan Wei. 

It was kind of you for listing down the Dreyfus Levels. Dreyfus helps us realize (professional) practitioners need to work on becoming Proficient to truly take advantage of Agile. 

Here's another article by Andy Hunt "10 down, A thousand to go"  http://pragprog.com/magazines/2011-02/agile--  for a Prags perspective. This is from Agile @ 10 where Ten Authors of The Agile Manifesto reflect on the Tenth Anniversary. Again I think people with enough context can relate to this more that people who's just beginning with Agile. Speaking of context here's a key note video by Andy himself at Ruby Midwest 2011  http://www.youtube.com/watch?v=IID8fD-uKSU for those who are visual/spatial and have difficulty parsing text :)

For the Shu-Ha-Ri concept:

  (1) Shu stage the student copies the master锟斤拷s moves as perfectly as possible.

  (2) Ha stages he or she understands the principles well enough to depart from rigid mimicry and try different variations.

  (3) Ri the martial artist has reached a point of mastery. Her reflexes and thinking are well-formed and she requires little conscious guidance to carry out combinations of movements.

I concur in respect to the philosophical and practical application of this thinking as journeymen work towards mastering our craft which you have elaborated well enough already. There are similarities to the music profession as well.

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:  

  (1) Imitate

  (2) Assimilate

  (3) Innovate

This echoes the cycle of training in martial arts. So among other things, we need to look at ways to keep as much existing expertise as we can in the project itself; non of this progression will help if practitioners don't stay in the field. So I believe we should strive to keep expertise in practice. Thus, keep practising in order to remain expert. There's no expertise without experience, and there's no substitute for experience - but we can work to make the experience we have more efficient and more effective by becoming more aware about it given context.

- Edward 

On Thu, Apr 5, 2012 at 9:23 PM, Panwei Ng <pan...@ivarjacobson.com> wrote:

Hi,

 

I also can锟斤拷t help but drop in. Thanks Edward for the reference to the Dreyfous Model with the 5 levels:

(1)    Novice who needs recipes and step by step guidance,

(2)    Advance Beginners who still cannot comprehend the big picture yet

(3)    Competent people who take the initiative and are resourceful

(4)    Proficient folks who can self-correct.

(5)    Expert who can work on intuition.

It is a short chapter and can be read in 5 to 10 minutes 锟紺 it is worth the time.

 

I recall Alistair Cockburn who referred to Shu-Ha-Ri of Bushido (Japanese martial arts) (see http://alistair.cockburn.us/Shu+Ha+Ri ).

(1)    Shu. When learning something, one starts with Shu (learn just one method and adhere to that method). It is important to learn just **one** method now as otherwise the novice gets very confused.

(2)    Ha 锟紺 At this point, the student branches out and appreciate the difference between reality and what he knows. He learns from others how to fill the gap

(3)    Ri 锟紺 At this point, the individual understand deep principles and is able to transcend methods. He can invent solutions.

 

In software teams (an organizations), we usually a mix of people at  different level of competencies in different areas. Someone might be expert in Java, but not so competent when it comes to say system/cyber security. Someone might be expert in web server/database performance tuning, but a novice when it comes to intellectual property and dealing with lawsuits.

 

It is not easy (read impossible) to learn everything and become expert in everything immediately. As such, the tendency is to have some kind of specialization. The trend today is for companies to value T-shaped people (people who are experts in a particular area, but broad knowledge in many areas) as opposed to I-shaped people (who have only knows one area). (see http://en.wikipedia.org/wiki/T-shaped_skills )

 

My opinion is as follows:

1.       Shu-Ha-Ri. It is begin with one approach, but do not be stuck in that and be too religious in that one approach/mindset. Be humble to broaden the mind. Be humble to learn from others.  

2.       Many times, no-knowledge is better that partial knowledge. There is an Arabian saying:

a.       He who knows that he knows 锟紺 He is wise, follow him.

b.      He who knows not that he knows  - He is asleep, wake him

c.       He who knows that he knows not 锟紺 Teach him

d.      He who knows not that he knows not 锟紺 He is a fool.

3.       Each person must understand his/her core strength and value to the development team/organization. If it is expertise in code/design, good. If it is expertise in leading people, getting people to work together, inspiring people, good! If it is communicating with customer representative, having an eye for market trends/needs, excellent.  Build that core strength. But do not neglect other areas. Be that T-shaped guy, but let the T be a T with a thick stem, rather than a thin stem.

4.       Be it 锟斤拷managers锟斤拷 or 锟斤拷programmers锟斤拷, I think it is important to be T-shaped.

5.       In an organization, there will be a mix of novice and experts. The key idea challenge is how to make the best use of the current situation, and how to bring the current situation to the next higher level, working under the constraints.

6.       Lean principles says 锟斤拷Go See for Yourself锟斤拷. In such discussion as this, it is very hypothetical. Idealism can often be mistaken as arrogance. It is important to see what is on the ground at a specific company. Then perhaps some concrete/actionable recommendations can arise. It is good to see a lively debate here, but I do not think that it will change anyone锟斤拷s opinion on things.

 

The success of a company depends on many many factors. Software development is just one of them. There are many other factors, such as customer relationship, hitting the right business model, following/leading the right trend, etc. Many times, those who make money are those who are in the right company than those with the right competencies. The right companies will often give the environment to build the right skills and grow in many areas.

 

Incidentally, amongst the people I work with, are telecom equipment providers.

1.       I know of a major telecom equipment provider (let锟斤拷s call this company A) who just shut down their German operations. Everyone was let off 锟紺 programmers and managers.

2.       I also know of another telecom equipment provider (let锟斤拷s call this company B) had risen rapidly over that last 10 years and had put many in this field out of business. This telecom equipment provider has many managers who do not code, but a number of them recognize the value of code, and see the total value chain.

[Bas Vodde]

Imitate and cut n paste are quite different :)

With cut n paste, there is no attempt to learn anymore...

Bas

On 06-Apr-2012, at 1:35 PM, James Chua wrote:

> (1) Imitate
>
>
>
> yes. cut and paste is bread and butter in my short software programming career.
>
>
>

> Date: Fri, 6 Apr 2012 11:44:56 +0800
> Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB
> From: edwardche...@gmail.com
> To: agilesi...@googlegroups.com
>
> Agree Duncan. This is why craftsmanship model sits well in our profession i.e. (1) Apprentice (2) Journeyman (3) Master Craftsman because it follows this universal pattern.
>
> Picasso is obviously a great example of a Master Craftsman :)
>
> On Fri, Apr 6, 2012 at 11:32 AM, Duncan Campbell <duncan.su...@googlemail.com> wrote:
>
>
> Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:
>
> (1) Imitate
>
> (2) Assimilate
>
> (3) Innovate
>
>
> This reminds me of looking at the development of Picasso's work. Picasso started of learning the basics: learning how to draw and paint the real world very well. Later Picasso drew the real world as a master, capturing the profile of an object with just a single stroke of the brush or pencil. Finallly Picasso experimented, ending up with eyes on the same side of the face, etc...
>
>
>
>
> On 6 April 2012 10:59, Edwardcher Monreal <edwardche...@gmail.com> wrote:
> Thanks Pan Wei.
>
> It was kind of you for listing down the Dreyfus Levels. Dreyfus helps us realize (professional) practitioners need to work on becoming Proficient to truly take advantage of Agile.
>
> Here's another article by Andy Hunt "10 down, A thousand to go" http://pragprog.com/magazines/2011-02/agile-- for a Prags perspective. This is from Agile @ 10 where Ten Authors of The Agile Manifesto reflect on the Tenth Anniversary. Again I think people with enough context can relate to this more that people who's just beginning with Agile. Speaking of context here's a key note video by Andy himself at Ruby Midwest 2011 http://www.youtube.com/watch?v=IID8fD-uKSU for those who are visual/spatial and have difficulty parsing text :)
>
> For the Shu-Ha-Ri concept:
>

> (1) Shu stage the student copies the master’s moves as perfectly as possible.

>
> (2) Ha stages he or she understands the principles well enough to depart from rigid mimicry and try different variations.
>
> (3) Ri the martial artist has reached a point of mastery. Her reflexes and thinking are well-formed and she requires little conscious guidance to carry out combinations of movements.
>
> I concur in respect to the philosophical and practical application of this thinking as journeymen work towards mastering our craft which you have elaborated well enough already. There are similarities to the music profession as well.
>
> Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:
>
> (1) Imitate
>
> (2) Assimilate
>
> (3) Innovate
>
> This echoes the cycle of training in martial arts. So among other things, we need to look at ways to keep as much existing expertise as we can in the project itself; non of this progression will help if practitioners don't stay in the field. So I believe we should strive to keep expertise in practice. Thus, keep practising in order to remain expert. There's no expertise without experience, and there's no substitute for experience - but we can work to make the experience we have more efficient and more effective by becoming more aware about it given context.
>
> - Edward
>
> On Thu, Apr 5, 2012 at 9:23 PM, Panwei Ng <pan...@ivarjacobson.com> wrote:
> Hi,
>

> I also can’t help but drop in. Thanks Edward for the reference to the Dreyfous Model with the 5 levels:

> (1) Novice who needs recipes and step by step guidance,
> (2) Advance Beginners who still cannot comprehend the big picture yet
> (3) Competent people who take the initiative and are resourceful
> (4) Proficient folks who can self-correct.
> (5) Expert who can work on intuition.

> It is a short chapter and can be read in 5 to 10 minutes – it is worth the time.

>
> I recall Alistair Cockburn who referred to Shu-Ha-Ri of Bushido (Japanese martial arts) (see http://alistair.cockburn.us/Shu+Ha+Ri ).
> (1) Shu. When learning something, one starts with Shu (learn just one method and adhere to that method). It is important to learn just **one** method now as otherwise the novice gets very confused.

> (2) Ha – At this point, the student branches out and appreciate the difference between reality and what he knows. He learns from others how to fill the gap
> (3) Ri – At this point, the individual understand deep principles and is able to transcend methods. He can invent solutions.

>
> In software teams (an organizations), we usually a mix of people at different level of competencies in different areas. Someone might be expert in Java, but not so competent when it comes to say system/cyber security. Someone might be expert in web server/database performance tuning, but a novice when it comes to intellectual property and dealing with lawsuits.
>
> It is not easy (read impossible) to learn everything and become expert in everything immediately. As such, the tendency is to have some kind of specialization. The trend today is for companies to value T-shaped people (people who are experts in a particular area, but broad knowledge in many areas) as opposed to I-shaped people (who have only knows one area). (see http://en.wikipedia.org/wiki/T-shaped_skills )
>
> My opinion is as follows:
> 1. Shu-Ha-Ri. It is begin with one approach, but do not be stuck in that and be too religious in that one approach/mindset. Be humble to broaden the mind. Be humble to learn from others.
> 2. Many times, no-knowledge is better that partial knowledge. There is an Arabian saying:

> a. He who knows that he knows – He is wise, follow him.

> b. He who knows not that he knows - He is asleep, wake him

> c. He who knows that he knows not – Teach him
> d. He who knows not that he knows not – He is a fool.

> 3. Each person must understand his/her core strength and value to the development team/organization. If it is expertise in code/design, good. If it is expertise in leading people, getting people to work together, inspiring people, good! If it is communicating with customer representative, having an eye for market trends/needs, excellent. Build that core strength. But do not neglect other areas. Be that T-shaped guy, but let the T be a T with a thick stem, rather than a thin stem.

> 4. Be it “managers” or “programmers”, I think it is important to be T-shaped.

> 5. In an organization, there will be a mix of novice and experts. The key idea challenge is how to make the best use of the current situation, and how to bring the current situation to the next higher level, working under the constraints.

> 6. Lean principles says “Go See for Yourself”. In such discussion as this, it is very hypothetical. Idealism can often be mistaken as arrogance. It is important to see what is on the ground at a specific company. Then perhaps some concrete/actionable recommendations can arise. It is good to see a lively debate here, but I do not think that it will change anyone’s opinion on things.

>
> The success of a company depends on many many factors. Software development is just one of them. There are many other factors, such as customer relationship, hitting the right business model, following/leading the right trend, etc. Many times, those who make money are those who are in the right company than those with the right competencies. The right companies will often give the environment to build the right skills and grow in many areas.
>
> Incidentally, amongst the people I work with, are telecom equipment providers.

> 1. I know of a major telecom equipment provider (let’s call this company A) who just shut down their German operations. Everyone was let off – programmers and managers.
> 2. I also know of another telecom equipment provider (let’s call this company B) had risen rapidly over that last 10 years and had put many in this field out of business. This telecom equipment provider has many managers who do not code, but a number of them recognize the value of code, and see the total value chain.

> 3. Incidentally, the company A was one of the birthplace of agile development. In recent years, the agilistas from company A left company A and became agile coaches to other companies.
>
>
> Cheers
> -- Pan Wei
>
>
>
>
> From: agilesi...@googlegroups.com[mailto:agilesi...@googlegroups.com] On Behalf Of Edwardcher Monreal
> Sent: Thursday, 5 April, 2012 4:06 PM
> To: agilesi...@googlegroups.com
>
> Subject: Re: [agilesingapore] Re: Interesting discussion about IT industry @ SRB
>
>

> Sorry guys, can't help but drop in. Dreyfus Model anyone? Just taking another pragmatic perspective. For those who haven't heard about it (and are patient enough to read through) you can check outhttp://media.pragprog.com/titles/ahptl/chap2.pdf. Interestingly, section 2.4 is cut out which somehow paraphrases most if this threads discussion (so for those who have the book feel free to revisit the chapter). For those not so patient, you can view a video about "Herding Race Horses and Racing Sheep" by Dave Thomas here http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas

[Ivan]

> Interesting, but shouldn't there be a distinction between people being an
> amateur to a professional level and those professionals who perform at an
> amateur level...?

"Amateur" is underrated because people don't read etymology dictionaries.
"Professional" is overrated because of our broken educational system
(with strong emphasis on degrees, certificates and extreme
specialization).

[Bas Vodde]

Hi Edward and Pan Wei,

Though, I agree with nearly all you are writing, I'm unclear how it relates to the earlier discussion related to manegement? :) Please clarify :P

Bas

[Edwardcher Monreal]

Hi Bas,

It was to follow your point on the management (verb) is a skill. It also means that it needs to be progressed. Hence, my reference to Dreyfus. I also concurred to previous comments that management (noun) to remain relevant must have enough grounding on actual practices to work. Otherwise they end up being just a detached observer.

Among other things, we need to look at ways to keep (as much) existing expertise as we can inside projects whether it's agile or not; non of this progression will help if practitioners don't stay in the field or keep relevant skills that relate to concrete technicalities.

This also relates to your comment that staying technical will pay off in the end as long as you update your knowledge constantly which I fully agree :)

Edward 

[Edwardcher Monreal]

Thanks Bas. The take away item here is progression. Obviously, imitate can also attribute to R&D "Rip of and Duplicate" if taken with out context :) 

[Bas Vodde]

Ah oki :) Now it makes sense :P

Bas