Software Engineer’s Blog

Software Engineering weblog

Domain Knowledge or Technical Skills?

Advertisements

June 4, 2011 Posted by | software engineering, Software Engineering Career | Leave a comment

Key skills for a successful career in Software Engineering

Key Skills for a successful career in Software Engineering

Read more

May 28, 2011 Posted by | software engineering, Software Engineering Career | Leave a comment

Forces in Software Engineering

Forces in Software Engineering

Read more

May 27, 2011 Posted by | software engineering, Software Engineering Career | Leave a comment

A tribute to a master!

I have come to know only today; sad to realize that Prof. Watts Humphrey is no more!

I remember listening to his lecture during a conference on software engineering organized by Computer Society of India in mid nineties.

Software development community used to be very small in those times and far less connected. I was a programmer, cocooned in glass houses with mainframes and PCs; a simple world of FORTRAN, COBOL, C and C++. Interaction was truly an eye opener for me, and encouraged me take a decisive plunge into software engineering and software quality. My journey continues, though the master who set me on the journey is no more!

I would like to clarify that, barring my initial interaction during the conference, I have never met him in person. But I had been following him though his published works.

In a career spanning more than two decades in software development, I have seen many advocates of software engineering and software quality crashing with dogmas and myopic vision, without adequately appreciating various dimensions of software development, and dust has not yet settled.

As a person committed to software engineering and software quality, Prof. Watts Humprey had not lost sight of various dimensions involved. Rather, he was able to effectively manage these, and synthesize changes continuously into his work

Though he no more amidst us, I believe, his work and spirit would continue to inspire and guide us, as software development evolve to engineering discipline

What you leave behind is not what is engraved in stone monuments, but what is woven into the lives of others. ~ Pericles

November 3, 2010 Posted by | software engineering, Software Quality | Leave a comment

Outsourcing: sustaining business growth

Companies in India have been into outsourcing model, with reasonable amount of success so far. Many companies of recent origin has been shot to prominence, living standards of a section (yes, it is only a tiny fraction still but rest of India is still starving) has improved, quality of infrastructure is improving (of course, not yet how it should be but it is changing). Good but I think, it is not yet time for India Inc to rest on its laurels.

Why talk about it now? I came across an interesting write up ‘When will TCS become the next Accenture?’. It is an eye opener; it should be one. As per the write up, TCS ranks as #1 in software services/outsourcing and it is (but it is only) 9th largest software services company in the world; where are the rest? What is India Inc’s share in global business?

Being successful is one thing, sustaining and building up on earlier successes is yet another. if first part is hard, second is harder. I am not referring to packaging and marketing. They are required but that is not sufficient in itself. It is also about watching the ground we stand, it is about assessing the battlefield, and realigning strategies to evolving world.

What I find particularly interesting in the write up is ’employee utilization’. It brings hard questions on many intangible aspects of how business is functioning. What was ‘good enough’ for the past is not ‘good enough’ for the times ahead. It is not just about TCS. It is about India Inc

July 8, 2010 Posted by | Business, Management, Sociology, software engineering | Leave a comment

Essentials of software product development

1. Product vision (shared across all stakeholders of the project)
2. Product development plan (including risk identification, anticipation and mitigation)
3. Business case (justification: financial, market and technical)
4. Product architecture
5. Quality assurance and control
6. Maintain conceptual and structural integrity, and traceability, across all work products
7. Flexible but repeatable process
8. Pre-sales support plan (must include getting people in, getting them up to speed and retention of key resources)
9. Post-implementation support plan (must include getting people in, getting them up to speed, retention of key resources and knowledge persistence)
10. Product champion and a core team of code warriors of at least 3-4 years of experience
11. Infrastructure (including hardware, software and network)
12. Maintenance and change management plan

May 6, 2010 Posted by | Product Engineering, software engineering, Uncategorized | Leave a comment

IT 2010 and beyond!

Have you been looking at your crystal ball to see where IT is headed? Read Gartner Highlights: Key Predictions for IT Organizations and Users in 2010 and Beyond .

Particularly interesting, looking at it from India, is the prediction that ‘India-centric IT services companies will represent 20 percent of the leading cloud aggregators in the market by 2012’ is interesting.

Prediction that ‘mobile phones will overtake PCs as the most common Web access device worldwide by 2013’ indicates a changing landscape of computing. Computing was once a terrain for techno-geeks; it is now an irreplaceable aspect for everyday life, tool for business and platform for collaboration. Is it not yet time we get serious about it?

January 18, 2010 Posted by | Business, Collaboration, Product Engineering, software engineering, Software Quality, Value Based Software Engineering, Web 2.0 | Leave a comment

A hard look at software development business

Software Engineering: The Sociology of Software Project Failure is taking a hard look at current business, especially software development business, scenario. Statements sound harsh and politically inappropriate but many of them are, unfortunately, true.

Whether you agree with all observations and inferences made in the article, or not, it makes a compelling reading. It is pointing to fault lines in much touted software development business which prides itself in building social and business platform of future

I am reminded of Edsger W. Dijkstra: The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don’t master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.

Is it not yet time for business to wake up and own social responsibility?

January 17, 2010 Posted by | Software architecture, software engineering, Software Quality, Uncategorized | Leave a comment

Software Engineering, and changing software development business

Pardon me if my statement “software engineering is hard” sounds like a cliche. Lest it sound like I am parroting what Grady Booch has already stated “software development has been, is, and will remain a fundamentally hard profession” , let me elaborate. Here, my reference is not about software development being hard due to inherent complexities and invisible changes. It is rather about doing business in a changing world. What does that mean?

If one were to hibernate for about five years, world of software that you see would be quite a lot different. Changes may not be fundamental but there are significant changes. Well, as always, devil is in the details.

Let me elaborate going a little more specific now. Let us look at from two perspectives.

i) Analysis and design: Object Oriented Analysis and Design was quite in the hype early 1990s. I too joined the bandwagon, going around with the hammer looking for nails. Books on object orientation from those days talked at length about finding abstractions (identifying nouns etc) from requirements but these provided no scope for working with technical solutions. This was largely left to the discretion of individual practitioners. Experience of these practitioners were absorbed into standard Object Oriented Analysis and Design methodology taking it to its present bloated form. This happened in a span of 5-10 years

ii) Software Testing and Software Test Automation: Way back in 1990s, when popular testing tools like IBM Rational Robot (then called SQA Robot) and HP (Mercury) WinRunner came into being, popular success of web could hardly be envisaged. What was started off as tool to testing Windows GUI application had to extend itself into test web based application. These challenges continue as web 2.0, SoA, SaaS and mobile applications emerge. Point here is, when projects are undertaken in respective technologies, necessary tool support is not yet in place often. It is left to the individual teams to create custom solutions, which subsequently get into available tool sets.

These details are rarely look into, at decision making levels. Management of software development business are still desperately looking for mythical silver bullet solutions. Tool vendors still continue to promise magic wand solutions without looking into details before making such promises; well, it is again business! Developers are caught between …

I am not proposing a miracle solution. No such solution exists. My effort all along my consulting practice has been, and will be, to get business into sufficient level of details in decision making and helping them implement the same. With the scope for factoring in “Success Critical Stakeholders”, I find Value Based Software Engineering to hold potential as framework for such a deliberation.

January 13, 2010 Posted by | Business, Collaboration, Product Engineering, software engineering, Unified Process, Value Based Software Engineering | 1 Comment

Software engineering and Business

As a software engineering practitioner, I had been trying to apply software engineering practices in my daily business life. For instance, I started working with object oriented approach from 1993. I started use case modeling from 2002. I had started adopting agile practices since 2003. I started using function point estimation since 2004. As a subject matter expert, trainer and consultant, I had been helping my customers adopt these, and many more.

I help my team and my customers adopt because I do believe in these practices, and its business value. That said, my observation and experience has been each of them has evolved as the way of doing, through success in specific projects, then generalized and applied in many similar ones. Absolute care is called for when applying to a business context to be successful, because each context is different; people, business imperatives, priorities, technology, customer, user, … these differ.

Success here refers to business success. For example, when a project team is enabled on requirements definition, compliance to a defined standards is incidental; Compliance to a standard is rarely a real business objective/benefit. It, in turn, for another business objective/benefit. Actual success would mean achieving business objectives of well defined requirements. It may ,for instance, be a better communication across the team, control on scope creep etc. There are many cases where documentations are created but never referred except for process audit. It is pointless if compliance to standards is achieved but not the business objectives

Why am I saying? If you look around, you will find many situations where hours, or even days, are spent on creating documentation to convince an external auditor. I have seen this happening many times over. What is the business value delivered? Valuable productive time is being spent on a work item that should have been in place. These should have been part of the process, or by-product of the process, is being created for the sake of review. If it is truly valuable, why not account for it? If realities of business does not allow time for such documentation, why create them in the first place? Why recreate just for the sake of process compliance?

What is the issue? It is conflicting stakeholder interest, not mapped, not assessed, not tracked, not managed, … well, all stakeholders are not the same, and all stakeholder interests are not the same. Nor these remain the same; it may change with time. Practices which does not realize this, sooner or later degenerate into a ritual.

Let us accept. Practices of software engineering are not universal as in case of other engineering disciplines because underlying principles are not universal as in case of underlying scientific principles of other engineering disciplines; say scientific principles in mathematics or physics.

Software is a construction of human mind and software development is a teamwork. Therefore, management of software development business includes, but goes much beyond confines of, traditional science. Some of the underlying scientific fields are physics, mathematics, organizational behavior, economics, management science, and sociology

That makes it more than what a everyday business can chew; it is more of a potential research area. But life is not so complex either. We balance these forces everyday; we do it more out of experience and gut feel. Dynamic balancing is done in the context of everyday business. What interests me in value based software engineering is that it gives me a context and a framework for such balancing and a reasonably scientific analysis

January 4, 2010 Posted by | Business, software engineering, Software Quality, Value Based Software Engineering | 1 Comment