This is what I like about ‘R’. This one line is enough to apply a shade of color
to the area between two curves. Apart from the functional programming aspects(http://adv-r.had.co.nz/), I am interested in its powerful API’s used to visualize and parse data.

I was rather surprised to find these passages – copied below – in Fred Brook’s book “The mythical man-month” that was written a long time ago. I was browsing it again after a decade. So I thought I should collect my thoughts on this.

This particular organizational structure has caused me untold grief because as a technical lead I found the gap between these two groups too yawning to bridge. The two groups want to tear each other’s guts out at every meeting. Pure hatred !!

I have been specifically told by an MNC that a manager who has a large team will always get a better appraisal than a tech. arch. who builds systems with the assistance of a few. The top management is scared of equating the two groups for fear of antagonizing the project managers.

The general position “member of the technical staff” is a good way of merging the two groups. But the only way to completely abolish the difference is by making both groups work on project management as well as technical tasks, which is a tall order.

The other way is to encourage people to gain years of experience in their chosen field before moving up the ladder. This creates specialists. People in our companies don’t want to specialize in any field. So a business analyst is not a requirements expert. She should be. Actually no one is an expert requirements architect. So one of the most important fields is left without an expert. That hurts project success.

A project manager is not an expert in Earned Value Management or Statistical Process Control. Once we have specialists we will have humble people. Humility is a great leveler. Expertise gives confidence.

Plan the Organization for Change

Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the battle is thickest.

Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.

The barriers are sociological, and they must be fought with constant vigilance. First, managers themselves often think of senior people as “too valuable” to use for actual programming. Next, management jobs carry higher prestige. To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a “member of the technical staff.” Others, like IBM, maintain a dual ladder of advancement, as Fig. 11.1 shows. The corresponding rungs are in theory equivalent.

Figure 11.1. IBM dual ladder of advancement

It is easy to establish corresponding salary scales for rungs. It is much harder to give them corresponding prestige. Offices have to be of equal size and appointment. Secretarial and other support services must correspond. A reassignment from the technical ladder to a corresponding level on the managerial one should never be accompanied by a raise, and it should be announced always as a “reassignment,” never as a “promotion.” The reverse reassignment should always carry a raise; overcompensating for the cultural forces is necessary.

Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people.

Whenever talents permit, senior people must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. Doing this surely is a lot of work; but it surely is worth it!

The whole notion of organizing surgical-type programming teams is a radical attack on this problem. It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.

Furthermore, that structure is designed to minimize the number of interfaces. As such, it makes the system maximally easy to change, and it becomes relatively easy to reassign a whole surgical team to a different programming task when organizational

I am reading the Jan/Feb 2012 issue of IEEE Software that should strike a chord with Software engineers in the offshore industry. Even financial application developers are oblivious to the need for algorithms that are not always part of the J2SE kit or an astronomically priced tool that the management here favors.

The awareness is lacking and the motivation to read about and experiment with code and algorithms is missing.

I also read the interesting interview with David Chaiken, Chief Architect of Yahoo who visited the Chennai IIT and spoke about his work in Yahoo. I was in the audience and remember that he pointed out a particular bug ID that caused some Yahoo servers in the production data centre to mishebave after he deployed a release.

My question to him was about the testing procedures that Yahoo uses for such large-scale deployments and I was looking for some tips about testing distributed applications. He just replied that Yahoo tries to use agile testing principles in some cases.

I have to rememeber to urge the local IEEE chapter to invite such speakers more frequently and also involve the developer community. There were faculty and students on that day amongst the sparse audience.

I am stumped. Stanford research professor Sebastian Thrun and other professors are planning to organize and teach an entire university course in Computer Science !! I planned to but didn’t take their initial AI course but this is too good to miss. They are following it up with an entire degree course in CS. What attracts me is the open courseware concept and the self-driving car.

As a software developer I have firsthand knowledge of the lack of taste for algorithms/CS and how the entire offshore industry is stuck in a medieval mindset.
I am much obliged.

However you look at this endeavor this proves that if one is set on thinking audaciously action will follow. Shouldn’t this stir up our interest in CS and its application to seemingly mundane software engineering?

Description: This class, taught by one of the foremost experts in AI, will teach you basic methods in Artificial Intelligence, including: probabilistic inference, computer vision, machine learning, and planning, all with a focus on robotics. Extensive programming examples and assignments will apply these methods in the context of building self-driving cars. You will get a chance to visit, via video, the leading research labs in the field, and meet the scientists and engineers who are building self-driving cars at Stanford and Google.
Prerequisites: The instructor will assume solid knowledge of programming, all programming will be in Python. Knowledge of probability and linear algebra will be helpful.

Enterprise Architecture does not seem to be mentioned frequently by Agilists. The definitions are not set in stone but a Technical Architect who is more concerned with working Software and programming might be required to work with another Enterprise Architect. I have not met any EA yet most probably because they seem to be way up in the hierarchy.

I perceive rather wrongly a big gulf between Technical Architects and other business types but an EA is more concerned with alignment between IT and the business. This EA conference could help us understand an Enterprise Architect’s role.

Some of my posts have been laced with sarcasm but I could not help it. This is about the lack of interest in programming skills amongst my offshore colleagues. It is widely known that the offshore industry is driven my monetary goals. Business is the driving force here.
So we do not generally have to work through books like the ‘Structure and Interpretation of Computer Programs’ or algorithms to find employment. The interview process here favors UI frameworks and tools like Portals and ESB’s. The fundamentals are lost forever.
That is the prelude to the following drab Windows PowerShell program that I had to write recently. Not out of compulsion but out of curiosity. The PowerShell seems to pack a wealth of tricks and features and I discarded my original DOS shell script.