December 22, 2006

Recommended Reading for a Software professional

Here's something to read along the Career path

As a fresher out of college, as and when you step into the world of software development, I suggest you pick up a programming language book related to VB / C# / java based on your nature of work and technology, language used. 

After a couple of years of coding its time to reflect on your performance and make necessary corrections Code Complete (2nd Edition) by Steve Mc Connell is an excellent book which will help you in this task

2 more years down the lane you just don’t do coding only, you also involve in Requirements analysis, Design etc. Its time to understand Architecture styles, patterns, unit operations, qualities, etc. there are n no. of books in the market. I suggest you can pick up books by Yourdon, Booch, Martin Flower, Luke Hoffmann, Karl Weigers, Paul Clements etc. check out architecture section of  www.sei.cmu.edu

(I will probably write a separate article on R & D I mean Reqmnts & Design)

By this time you would have followed one or more processes during the development life cycle, its time to uderstand the importance of the various process steps, terminologies etc, SDLC, Waterfall, Spiral, Agile, Lean  etc. for anything on the traditional process, I suggest you check out www.sei.cmu.edu Process Management section. For Agile check out http://www.agilealliance.org/  and for anything on Lean  which laso happens to be my favourite check out books by Poppendieck, Lean software development & implementing Lean

Around this time you would have slowly transitioned to a supervisory role and have probably started making decisions on behalf of the team. You would have taken a few right decisions & made a lot of mistakes too. You have reached a transition point where you need to get things done from others. At this point you should read Rapid Development by Steve Mc Connell, It will help you not only reflect on your mistakes, but also learn from others mistakes and how to handle various real life scenarios. You should also read books from Gerald Weinberg most of them are classics

Couple of years down the line you are ready for Project Management resposibility, Its time to make plans, estimates, Monitor progress and Control execution. I recommend two books at this stage, Project Management - A managerial Approach by Jack Meredith and
Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner. These two books cover almost everything you need to know, to be a successful PM.

Iam sure I have missed out a lot of good books in this list, people will have different opinions, tastes and habits.
 
There are a lot of other books of general interest that I have read, and found very useful. I have restriced this list to Software development processes only, Hope it is useful

November 23, 2006

Rules for sound documentation

Documentation should be written from the point of view of the reader, not the writer.
Documentation should be organized for ease of reference, not just ease of reading.

Avoid repetition. Each kind of information should be recorded in exactly one place. This makes documentation easier to use and much easier to change as it evolves. It also avoids confusion, because information that is repeated is often repeated in a slightly different form, and now the reader must wonder: Was the difference intentional? If so, what is the meaning of the difference? What information was the author trying to convey to me that I am not picking up?

Avoid unintentional ambiguity
One of the greatest sources of ambiguity in architecture documentation are those ubiquitous box-and-line diagrams that people often draw on whiteboards or backs of napkins. While not a bad starting point, these diagrams are certainly not architectures. For one thing, the behavior of the components is not defined, and this (as we shall see) is a crucial part of the architecture. But beyond that, most of these diagrams suffer from ambiguity with respect to the component and connector types. Are the boxes supposed to be modules, objects, classes, processes, functions, procedures, processors, or something else? Do the arrows mean submodule, inheritance, synchronization, exclusion, calls, uses, data flow, processor migration, or something else?

Use a standard organization. Each document should conform to a standard, planned organization scheme, and this scheme should be made known to the reader. A standard organization offers many benefits. It helps the reader navigate the document and find specific information quickly (and so this is also related to the write-for-the-reader rule). But it also helps the writer of the document. It helps plan and organize the contents,

Record rationale. If you are documenting the results of decisions, record the decisions you eschewed and say why. Next year (or next month) when those decisions come under scrutiny or pressure to change, you will find yourself revisiting the same arguments and wondering why you didn’t take some other path. Recording rationale will save you enormous time in the long run, although it requires discipline to record in the heat of the moment.

Keep it current. Documentation that is incomplete, out of date, does not reflect truth, and does not obey its own rules for form and internal consistency will not be used. Documentation that is kept current and accurate will be used. The reason is that, backed up by high-quality documentation, questions about the software can be most easily and most efficiently answered by referring the questioner to the appropriate document.

Review documentation for fitness of purpose.

(Source: I don’t recollect where I got this from, as and when I find out I wll update this)

November 13, 2006

Principles of Objectivism

The basic principles of Objectivism can be summarized as follows:
 
Metaphysics
"Reality, the external world, exists independent of man's consciousness, independent of any observer's knowledge, beliefs, feelings, desires or fears. This means that A is A, that facts are facts, that things are what they areand that the task of man's consciousness is to perceive reality, not to create or invent it." Thus Objectivism rejects any belief in the supernaturaland any claim that individuals or groups create their own reality.

 
Epistemology
"Man's reason is fully competent to know the facts of reality. Reason, the conceptual faculty, is the faculty that identifies and integrates the material provided by man's senses. Reason is man's only means of acquiring knowledge." Thus Objectivism rejects mysticism (any acceptance of faith or feeling as a means of knowledge), and it rejects skepticism (the claim that certainty or knowledge is impossible).

 
Human Nature
Man is a rational being. Reason, as man's only means of knowledge, is his basic means of survival. But the exercise of reason depends on each individual's choice. "Man is a being of volitional consciousness." "That which you call your soul or spirit is your consciousness, and that which you call 'free will' is your mind's freedom to think or not, the only will you have, your only freedom. This is the choice that controls all the choices you make and determines your life and character." Thus Objectivism rejects any form of determinism, the belief that man is a victim of forces beyond his control (such as God, fate, upbringing, genes, or economic conditions).

 
Ethics
"Reason is man's only proper judge of values and his only proper guide to action. The proper standard of ethics is: man's survival qua mani.e., that which is required by man's nature for his survival as a rational being (not his momentary physical survival as a mindless brute). Rationality is man's basic virtue, and his three fundamental values are: reason, purpose, self-esteem. Manevery manis an end in himself, not a means to the ends of others; he must live for his own sake, neither sacrificing himself to others nor sacrificing others to himself; he must work for his rational self-interest, with the achievement of his own happiness as the highest moral purpose of his life." Thus Objectivism rejects any form of altruismthe claim that morality consists in living for others or for society.

 
Politics
"The basic social principle of the Objectivist ethics is that no man has the right to seek values from others by means of physical forcei.e., no man or group has the right to initiate the use of physical force against others. Men have the right to use force only in self-defense and only against those who initiate its use. Men must deal with one another as traders, giving value for value, by free, mutual consent to mutual benefit. The only social system that bars physical force from human relationships is laissez-faire capitalism. Capitalism is a system based on the recognition of individual rights, including property rights, in which the only function of the government is to protect individual rights, i.e., to protect men from those who initiate the use of physical force." Thus Objectivism rejects any form of collectivism, such as fascism or socialism. It also rejects the current "mixed economy" notion that the government should regulate the economy and redistribute wealth.

 
Esthetics
"Art is a selective re-creation of reality according to an artist's metaphysical value-judgments." The purpose of art is to concretize the artist's fundamental view of existence. Ayn Rand described her own approach to art as "Romantic Realism": "I am a Romantic in the sense that I present men as they ought to be. I am Realistic in the sense that I place them here and now and on this earth." The goal of Ayn Rand's novels is not didactic but artistic: the projection of an ideal man: "My purpose, first cause and prime mover is the portrayal of Howard Roark or John Galt or Hank Rearden or Francisco d'Anconia as an end in himselfnot as a means to any further end."

Excerpts from www.aynrand.org

November 9, 2006

Fundamentals of IT consulting

Excerpts from fundamentals of IT Consulting from www.techrepublic.com

There are five basic concepts that can serve as a foundation for the IT advisory process:

  • Focus on the relationship: Identifying who the client is, and understanding the motivations, culture, history, fears, and goals of both the human being and the organization he or she represents, is one of the most difficult tasks in consulting. Your success in this task has much more bearing on the success or failure of your engagements than the technical discipline involved.

  • Clearly define your role: Setting the expectation with the client regarding exactly what you are there to accomplish, what tasks you are making a commitment to perform, what tasks you expect the client to perform, and where the boundaries of the relationship lie, is a key success factor for consultants.

  • Visualize success: It is the consultant’s central role to help the client draw a mental picture of the desired result of the engagement. Failure to do so results in the dreaded scope creep, in which the engagement never concludes because the expectations keep changing. Visualizing a successful result creates a common goal that all participants can agree upon and strive for together. Like the championship ring for a sports team, it is an unambiguous and motivational endpoint that clarifies the effort and helps clear away extraneous issues and barriers.

  • You advise; they decide: One of the most difficult tasks for consultants is to cast aside emotional attachment to their own advice. Many technicians fall in love with a particular solution or technology, and then lose interest in, or respect for, the client if he decides to take another approach. We must always remember that the client understands the complexities of his own environment, and that he lives with the result of his decision, while we move on to the next assignment.

  • Be oriented toward results: Consulting is more than advising, it is assisting clients to reach a goal. While some advisory relationships are strictly informational, most clients want us to not only recommend solutions, they want us to help implement them. Politics is often described as “the art of the possible,” a good definition for results-oriented consulting as well. By considering implementation issues throughout the engagement, such as corporate culture, readiness to change, training requirements, and corporate communications channels, we keep our eye on the realm of possibility, avoid getting sidetracked into the theoretical, and prepare the client for the real-world issues of implementation and system operation.

October 19, 2006

Reqmnt Analyst skills

The requirements analyst provides the essential function of bridging the understanding and perspective gap that lies between customers and developers. A competent analyst must combine communication, facilitation and interpersonal skills with some technical and business domain knowledge. Even a dynamite programmer or a system-savvy user needs suitable preparation before acting as an analyst.

The following capabilities are particularly important:
facilitation techniques, to lead elicitation workshops;
interviewing techniques, to talk with individuals and groups about their needs;
listening skills, to understand what people say and to detect what they might be hesitant to say;
writing skills, to communicate information effectively to users, managers and technical staff;
organizational skills, to make sense of the vast array of information gathered during elicitation and analysis;
interpersonal skills, to help negotiate priorities and resolve conflicts among project stakeholders;
domain knowledge, to have credibility with user representatives and converse effectively with them;
And modeling skills, to represent requirements information in graphical forms that augment textual representations in natural language

Requirements for a software product aren’t just lying around waiting for someone wearing a hat labeled “analyst” to collect them. At best, requirements exist in the minds of users,visionaries and developers, from which they must be gently extracted and massaged into a usable form. Often, they need to be discovered with guidance from a talented analyst, who helps users understand what they really need to meet their business needs and helps developers satisfy those needs. Few project roles are more difficult than that of requirements analyst. Few are more critical.

For More in-depth info refer to the book "Software Requirements" by Karl Weigers

October 17, 2006

process of learning

Excerpts from The Analysis of Mind by Bertrand Russell

The process of learning, which consists in the acquisition of habits, has been much studied in various animals.* For example: you put a hungry animal, say a cat, in a cage which has a door that can be opened by lifting a latch; outside the cage you put food. The cat at first dashes all round the cage, making frantic efforts to force a way out. At last, by accident, the latch is lifted. and the cat pounces on the food. Next day you repeat the experiment, and you find that the cat gets out much more quickly than the first time, although it still makes some random movements. The third day it gets out still more quickly, and before long it goes straight to the latch and lifts it at once. Or you make a model of the Hampton Court maze, and put a rat in the middle, assaulted by the smell of food on the outside. The rat starts running down the passages, and is constantly stopped by blind alleys, but at last, by persistent attempts, it gets out. You repeat this experiment day after day; you measure the time taken by the rat in reaching the food; you find that the time rapidly diminishes, and that after a while the rat ceases to make any wrong turnings. It is by essentially similar processes that we learn speaking, writing, mathematics, or the government of an empire.

October 13, 2006

DFSS Tools & GB Project

Organizations that believe in the Six Sigma paradigm, pursue the DFSS methodology religiously. Trainings are imparted, & the teams are GB certified. Is there an adequate understanding of the importance of DFSS, & the relevance of their tools. Here is a brief on what I learnt from that exercise

One of the most important learning's of the whole process is the importance of team work. All the activities revolve around Team work. 

Each of the tools revolve around this central theme to achieve a collective synergy.

When we used the SIPOC, we were able to figure out who are the concerned stakeholders? What did each of the stakeholder bring to the table. (inputs) and what were there expectations (outputs), what are the possible ways to transform these inputs to outputs (processes)

Since it is done in a team it ensures that all of the stakeholders inputs and their respective expectations are considered

When we used the TPM it ensured that all participants thoughts about the problem  are captured. There was a lot of tacit knowledge

At individual levels, Aspects that certain individuals were aware of, and some were not. Thus knowledge was shared (and captured) concerns  raised were addressed (through action items with assigned responsibilities & dates). Thus at the end of the exercise the collectively had enough information & were on the same page.

When we did an RCA as a Team, it ensured that we looked at the problem from different dimensions. It is true that as individuals we may not have adequate information on all dimensions (6M) of the problem. But collectively as a team we were able to get a broader perspective on the root causes

Again when the team did an FMEA, each of us had our own opinion on what could fail and what the impact would be. All of which were captured. Collectively we were able to decide on the probability / severity of each of these. We were able to come up with some good ideas on how to mitigate them effectively.

Other then the above ones we did use the QFD, C&E, Pareto, Pugh Matrix etc… As individuals each one of us has his own opinion on what is important, relevant, of priority etc. In a team sometimes few individuals and their ideas dominate. To Arrest such possibilities these tools helped us to Quantitatively figure out what was important, relevant, of priority and vital.      

Now does this ensure that we reach six sigma levels of quality? Definitely not.

However what it does ensure is that "you have taken into consideration all stakeholders requirements, considered various alternatives at each stage of the project, made the right choices or taken optimum decisions, not just as individuals, but collectively as a team. Thus minimizing the possibilities of making mistakes".

October 9, 2006

What if I start my own enterprise?

What if I start my own MNC, how would it be?

There are 38 million businesses in the U.S. alone that have less than 10 employees. Wow... what about APAC & EMEA ? That’s a substantial number. Hmmm Think about it .... do you see any opportunitiies…

there are dozens of travel sites each claiming that they have the lowest Air fares & hotel rentals, largest no. of destinations listed. ....do you see any opportunity around travel .... I do :-)

Organizations have processes through which they communicate between stakeholders to accomplish tasks. There is opportunity there ... did you spot it? Think workflow …. :-)

Is there an opportunity in bringing the investors, managers and the nerds together You will ofcourse also need the marketing folks ...now that would be a winning formula

....
I would probably call my enterprise an MNC… why?  Simple….motto is Mentor good people Nurture good ideas Create sustainable future

De Bono's DATT Techniques

Direct Attention Thinking Tools (DATT)™

We’ve all said it. Too much to do, too little time. But what if you could really focus. Cut out all the distractions and funnel your thoughts until you drill down to the right action? Think how much more you could accomplish. DATT gives you 10 simple strategies for sharpening your perception and focusing your thinking in a more comprehensive, effective and efficient way. DATT will enable you to have a broad and inclusive viewpoint. The tools create a framework for defining a situation. That framework will improve your ability to consider consequences before you take action.

Our modern lives - both business and personal - are very fast paced and full of action. We often confuse action with accomplishment and frequently jump to action without enough thought. We love to take action and see what happens - if it’s good, we keep going; if it’s bad, we stop and clean up the mess we have created. Sure, it’s better than doing nothing at all but it’s inefficient at best and costly at its worst.

Tool 1 -- Consequences and Sequels - Look ahead to see the consequences of an action, plan, decision, or rule.

Tool 2 -- Plus, Minus, Interesting - Ensure that all sides of a matter have been considered before a decision or commitment is made.

Tool 3 -- Recognize, Analyze, Divide - Break a larger concept into smaller, more manageable parts.

Tool 4 -- Consider All Factors - Explore all factors related to an action, decision, plan, judgment, or conclusion.

Tool 5 -- Aims, Goals, Objectives - Focus directly and deliberately on the intentions behind actions.

Tool 6 -- Alternatives, Possibilities, Choices - Deliberately try to find other ways.

Tool 7 -- Other People’s Views - Put yourself in others’ shoes.

Tool 8 -- Key Values Involved - Ensure that your thinking serves your values.

Tool 9 -- First Important Priorities - Select the most important ideas, factors, objectives, consequences, etc.

Tool 10 -- Design/Decision, Outcome, Channels, Action - Direct attention to the outcome of the thinking and action that follows.

For More on DATT - http://www.debonothinkingsystems.com/

October 7, 2006

Project Metrics

Metrics Based Management is something that is followed by most organizations. But how effective are these organizational metrics, or for that matter are the numbers collected at the project levels realistic. In my opinion these numbers are skewed to a very large extent.  These numbers could end up being rigged all along to make it more pleasant or in line with expectations. Alternatively lack of adequate knowledge or a conviction with regards to these measurements, at the bottom of the pyramid has further impaired the quality and dependability of these numbers.

What is the solution?

To begin with we need to understand that just as any two humans are dissimilar, two projects are different. Hence, how they are measured may also differ. So it is imperative that project team decides on what to measure, when to measure, & how to measure? Offcource before all of that, they need to have a shared understanding of why they need to measure.

That’s right. The Need for measurement, consider ourselves, are we better off today than we were yesterday? We all do know that we are better off, but how do we convince others about it? We might say we are earning more today than what we were earning yesterday, or we are more contended today with our lives when compared to the past. We generally demonstrate to the society our state of well being by some form of materialistic gains, or the society judges our wellbeing by some form of tangible gains and losses.

Similarly, we need some tangible measurements to show progress in projects over a period of time.Now, here are a few ideas to start working towards a meaningful measure for your project. This approach is a combination of the GQM (Goal-Question-Metric) Method and the Balanced Scorecard approach.

List down the goals of your project, Are they SMART enough? (Specific, Measurable, Achievable, Realistic, Timely) For each Goal list down the strategies to fulfill the Goal, Next for each of the strategies list down the specific tasks that need to be performed, now for each task, ask the question how would you know when the task is completed? That is what you would be measuring or would be your scale of measurement. This is called the GQM Method. (this is my own interpretation, so I have simplified it for my own understanding)

Let us next look at the Balanced Scorecard Approach, Consider you are a member of a team currently involved in a project. How do you know that you are perfroming well? Let us suppose that the Performance needs to be evaluated every month,

In the past one month (or period under consideration)
a. What did we do? (Towards meeting the project goals)
b.How did we do it? (Did we improve on the way we do things?)
c.What did we learn? (Did we increase our ability to do similar tasks?)
d.What obstacles are we facing? (What Risks do we percieve? How do we mitigate them?)

On each of these questions above, get the views of the team, management & customer. Here we are trying to evaluate holistically from different viewpoints rather than just evaluating the deliverables. (As i said, this is my own interpretation…:-)  grossly simplified ... )

Within your project you could use both of these techniques to derive some meaningful measures.A good understanding among the Team about the need for measurement, would go a long way in improving the measurement process

October 5, 2006

Principles of UI Design

These are the most important principles of good UI Design

Access: "Good systems are usable--without help or instruction--by a user having knowledge and experience in the application domain but no experience with the system."

Efficacy: "Good systems do not interfere with or impede efficient use by a skilled user having substantial experience with the system."

Progression: “Good systems facilitate continuous advancement in knowledge, skill, and facility and accommodate progressive change in usage as the user gains experience with the system."

Support: “Good systems support the real work that users are trying to accomplish, making it easier, simpler, faster, or more fun.”

Context: “Good systems are suited to the conditions and environment of the actual operational context within which they are deployed.”

Visibility: Keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Instead of WYSIWYG, use WYSIWYN: What-You-See-Is-What-You-Need.

Feedback: Keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions using clear, concise, and unambiguous language familiar to users.

Structure: Organize the user interface purposefully, in meaningful and useful ways that put related things together and separate unrelated things based on clear, consistent models that are apparent and recognizable to users.

Reuse: Reduce the need for users to rethink and remember by reusing internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency.

Tolerance: Be flexible and tolerant, preventing errors where possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonably; reduce the cost of mistakes and misuse by allowing undoing and redoing.

Simplicity: Make simple, common tasks simple to do, communicating straightforwardly in the user's own language and providing good shortcuts that are meaningfully related to longer procedures.

Source: Web

October 3, 2006

Success Strategies


"Peter Leerskov" Reviews the book  The first 90 days by Michael Watkins (from Amazon customer reviews)

The book outlines ten strategies that will shorten the time it takes you to reach what Watkins calls the breakeven point: the point at which your organization needs you as much as you need the job. Here they are ... the ten strategies:

1. PROMOTE YOURSELF. Make a mental break from your old job. Prepare to take charge in the new one. Don't assume that what has made you successful so far will continue to do so. The dangers of sticking with what you know, working hard at doing it, and failing miserably are very real.

2. ACCELERATE YOUR LEARNING. Climb the learning curve as fast as you can in your new organization. Understand markets, products, technologies, systems, and structures, as well as its culture and politics. It feels like drinking from a fire hose. So you have to be systematic and focused about deciding what you need to learn.

3. MATCH STRATEGY TO SITUATION. There are no universal rules for success in transitions. You need to diagnose the business situation accurately and clarify its challenges and opportunities. The author identifies four very different situations: launching a start-up, leading a turnaround, devising a realignment, and sustaining a high-performing unit. You need to know what your unique situation looks like before you develop your action plan.

4. SECURE EARLY WINS. Early victories build your credibility and create momentum. They create virtuous cycles that leverage organizational energy. In the first few weeks, you need to identify opportunities to build personal credibility. In the first 90 days, you need to identify ways to create value and improve business results.

5. NEGOTIATE SUCCESS. You need to figure out how to build a productive working relationship with your new boss and manage his or her expectations. No other relationship is more important. This means having a series of critical talks about the situation, expectations, style, resources, and your personal development. Crucially, it means developing and gaining consensus on your 90-day plan.

6. ACHIEVE ALIGNMENT. The higher you rise in an organization, the more you have to play the role of organizational architect. This means figuring out whether the organization's strategy is sound, bringing its structure into alignment with its strategy, and developing the systems and skills bases necessary to realize strategic intent.

7. BUILD YOUR TEAM. If you are inheriting a team, you will need to evaluate its members. Perhaps you need to restructure it to better meet demands of the situation. Your willingness to make tough early personnel calls and your capacity to select the right people for the right positions are among the most important drivers of success during your transition.

8. CREATE COALITIONS. Your success will depend on your ability to influence people outside your direct line of control. Supportive alliances, both internal and external, will be necessary to achieve your goals.

9. KEEP YOUR BALANCE. The risks of losing perspective, getting isolated, and making bad calls are ever present during transitions. The right advice-and-counsel network is an indispensable resource

10. EXPEDITE EVERYONE. Finally, you need to help everyone else - direct reports, bosses, and peers - accelerate their own transitions. The quicker you can get your new direct reports up to speed, the more you will help your own performance.

September 29, 2006

Need for philosophy


From "Unpopular Essays" by Bertrand Russell

It is not to be supposed that young men and women who are busy acquiring valuable specialized knowledge can spare a great deal of time for the study of philosophy, but even in the time that can easily be spared without injury to the learning of technical skills.

philosophy can give certain things that will greatly increase the student's value as a human being and as a citizen. It can give a habit of exact and careful thought, not only in mathematics and science, but in questions of large practical import. It can give an impersonal breadth and scope to the conception of the ends of life. It can give to the individual a just measure of himself in relation to society, of man in the present to man in the past and in the future, and of the whole history of man in relation to the astronomical cosmos.

By enlarging the objects of his thoughts it supplies an antidote to the anxieties and anguish of the present, and makes possible the nearest approach to serenity that is available to a sensitive mind in our tortured and uncertain world.

Product vs Project


The Product Manager, is continously striving to improve the product he wants to incorporate any new ideas that he comes across to make the product better. His primary concern is to make a world class product. He strives towards perfection in product quality. His performance is measured against the quality of the product and market reactions or customers feedback. He wants to add features and incroporate all of these feedback. In summary, do whatever is required to make the product more sellable at the earliest possible timeframe.

The Poject Manager on the other hand is judged by various other parameters, He sets a Scope of what needs to be done and derives the

Requirements from that scope. Any requirments that need to be added or changed (to improve the product) is considered as outside the scope. It would require an approval from a change control board. He has milestones to reach, schedules to meet, and deliverables to be given  with a limited set of resources. His performance is measured against these above parameters including Cost. Within Budget, On Time is his motto.

A good relationship between them can create a Synergy resulting in a Win-Win solution for both;




 


September 23, 2006

Snippets of wisdom - Part 1

  • It is incredibly easy to get caught up in an activity trap in the busy-ness of life, to work harder and harder at climbing the ladder of success, only to discover, its leaning against the wrong wall
  • We are all in the gutter, but some of us are looking at the stars
  • The ugliest of trades have their moments of pleasure now if i were a grave digger or even an hangsman, there are some people i would work for with a great deal of enjoyment
  • The reasonable man adopts himself to the world, The unresonable one persists in trying to adopt the world to himself. Therefore all progress depends on the unresonable man
  • So long as all the increased wealth which modern progress brings, goes but to build up great fortunes to increase luxury and make sharper the dfference berween house of have's and the house of wants progress is not real and cannot be permanent

.....from various sources.....

September 22, 2006

Role of a Software Architect

In the construction industry, the Architect understands the client needs & translates them into various blueprint drawings such that the concerned Construction team members have clarity on what they need to do.

For example, the masonry team needs to know the dimensions of various rooms, the wall thickness etc. The Electrical engg needs to know where the wires need to be drawn and concealed within the walls, the necessary switch/ plug points, the required electrical fixtures etc. The Sanitary engg needs to know where the water outlets are required and the drainage layout. Pipe thickness specs etc. The painter needs to know what color scheme is required. The carpenter needs to know the dimensions of the cupboards, shelves, Door/ window designs

All of these activities have to happen in tandem with the required sequence or co-ordination. You don’t want to remove the polished tiles in the bathroom to lay the pipes for drainage, neither do you want the electrical engineer to make slits in the newly painted walls to conceal electrical wires

Architect here is responsible for giving the detailed drawings or specs for each of the above activities and also indicating the sequence & co-ordination required. As the construction progresses the client may ask for changes, Architect here is responsible for evaluating the technical feasibility of the changes and instructing the construction team of the same.

This above description holds equally good for a software Architect.

Collecting customer Requirements & translating to a software design, Indicating the Use case scenarios for the UI Team, The Data flow and entity Relationship for the Database developer, the State Transition & object diagram for development of Middleware & business components, defining interface standards so that all of these work together seamlessly.

Just as in construction industry, here too, the software Architect is responsible for understanding the client needs & translate them into various blueprints, design specifications and drawings, such that the concerned Developers have clarity, on what they need to do, dependencies and optimum sequence of tasks.

Culture of innovation

Organizations that want to drive a culture of innovation across the company need to provide

a. the right eco-system for ideas to freely emerge
b. platforms where they can be freely debated
c. an environment where they can be nurtured

companies should be willing to provide their employee’s the necessary resources to experiment, make mistakes and learn from them. Over a period of time a knowledge repository of various experiments performed & the resulting learning’s is built. This will effectively result in a reduction in cycle time from idea conceptualization to realization

Being Innovative should progressively move from being just a buzzword, to learning creative skills, practicing, making it a habit to think of alternatives and outside the boundary across the organization.

Only at this stage we can truly say that the organization has imbibed a culture of innovation

September 14, 2006

In "Prometheus Unbound" by PB Shelley

I do like "IF" by rudyard kipling, but this piece below summarizes life better

To suffer woes which Hope thinks infinite;
To forgive wrongs darker than death or night;
To defy Power which seems omnipotent;
To love, and bear; to hope till Hope creates
From its own wreck the thing it contemplates;
Neither to change, nor falter, nor repent;
This like they glory, Titan, is to be
Good, great and joyous, beautiful and free;
This is alone Life, Joy, Empire, and Victory.