Software Engineer’s Blog

Software Engineering weblog

Software Engineering, and town planning analogy

I have seen many literature discussing Software Engineering relating software development to building construction, and a very few comparing it with town planning. Of course, I am no expert on civil engineering or town planning. My observations are from the perspective of observer.

Comparison with building construction is probably easier for any one to relate but I think it is quite a simplification. It helps to convey role of process formalism, team work and automation depending on scope and scale of project. Major point of disconnect, as I find, is in the epilogue. I think only a few, if at all any, building would need to adapt to change as a software must in its lifetime.

Let me clarify here that I am not referring to Software Development Life Cycle but rather time from its initial release for use till it is withdrawn from use, along with all its variants.I have not seen a natural death of a software so far. Either it is killed by its manufacturer by formally declaring End of Life, or it is killed by market and other forces. Well, then there are cases where software is continued to exist with its manufacturer withdrawing support. In general, it amounts to withdrawing ventilator. Is that a natural death or a forced one? I am not sure where to classify it

Coming back to town planning analogy, I find it is closer to software development, than a building construction, in the sense that it starts off in an ambitious plan and in a systematic manner. Over a period of time, town is goes through many changes as it change hands. People who are in charge of town planning, administration and management changes, each of them having their own ideas on how town should be. Market dynamics changes bringing in new possibilities. People living in town changes, and their needs. If you consider a modern town/city, what it was a few decades back and what it is now, you will realize changes and its impact. Town infrastructure had to adapt to accommodate evolving world. This is more visible in developing economies, partly due to ‘ad hoc’ town planning measures and often being at the receiving end of technology changes.

What makes software development further more complex is drastically shrinking timelines and its intangible, invisible nature.

August 3, 2011 Posted by | Software architecture, software engineering | 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

Architecting software in a new world

I came across an interesting O’Reilly web cast titled ‘O’Reilly Webcast: 10 Things Every Software Architect Should Know’. It is important ‘words of wisdom’ definitely for software architect

But, well, I believe much of it is quite relevant to many others as well, It is all the more so as software has become integral part of our every day life and software development is getting to be increasingly, as Grady Booch points out

December 20, 2009 Posted by | Business, IBM Rational, Model Driven Architecture, Rational Unified Process, Software architecture, software engineering, UML, Unified Modeling Language, Unified Process, Web 2.0 | Leave a comment

Software Architecture Guide

Are you looking for a good book on Architecture? Then, Microsoft Application Architecture Guide, 2nd Edition is a ‘must-read’. Though it is tuned to working with Microsoft technologies, much of topics covered have larger relevance. What I like about this book, compared to other books on software architecture, is practical relevance and ease of application

Hats off to Microsoft for bringing architecture from the elite glass house to developers’ workspace!

November 22, 2009 Posted by | Product Engineering, Software architecture, software engineering | Leave a comment

Google Wave

Is Google Wave a flop? I do not think so!

I have received an invite for Google Wave. Just started playing around with it. I am very much impressed with Google Wave.

What interests me is that the paradigm shift in communication; pretty much close to typical discussion. Discussions, in general, are not linear. It aligns very closely with human thought process and group activities like discussion. A good discussion, though would be centered on a topic, would also cover variety of related topics as well

Will it replace current forms like emails and IMs? It may not. Just as emails have not removed regular mail service.

Applications? Plenty. I would use it to record my own thought process and learning. I would also use it in any group activity, including software development.

Will it be a success? Well, there is more to success in the market than just realization of need and a good product. Critical mass, financial muscle, marketing push, competition and many other factors too play a major role

I am waiting for getting all my contacts into Google Wave. At this point, I am constrained by the number of invites that I can send

November 17, 2009 Posted by | Google Wave, Natural User Interface, Software architecture, software engineering, User Experience | Leave a comment

Demystifying jargons

Cloud computing and Software as a Service are among the most-talked-about jargons that has caught up with the computing world recently. What are they and how are they related. ‘ Understanding Public Clouds: IaaS, PaaS, & SaaS‘ in Keith Pijanowski’s Blog is a great write up attempting to demystify these jargons

October 19, 2009 Posted by | Software architecture, Uncategorized | Leave a comment

Consortium for IT Software Quality

As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.

World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.

People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project

Three dimensions of software quality

Three dimensions of software quality

It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers

August 20, 2009 Posted by | Agile, Product Engineering, Software architecture, software engineering, Software Factory, Software Quality, Software Testing, Testing, Uncategorized, Unified Process | 1 Comment

The 4+1 views of game development

This title is inspired by an IEEE paper 4+1 view model of software architecture.

The referred paper on software architecture suggests five views to organize description of software architecture. This helps to separation of concerns, with each view addressing concerns of a specific stakeholder role like programmer, designer, integrator, and system engineer with usage scenarios being central to all.

Similar approach helps to understand and manage game development. Note that I am referring to game development; not necessarily game architecture. It helps to look at game development from various perspective with gamer perspective being central to all.

The 4+1 views of game development

The 4+1 views of game development

These are not necessarily orthogonal; rather elements of one view are connected to elements of another just as in case of 4+1 view of software architecture. Each view helps define focus on specific stakeholder concerns, and in turn, roles, skill sets.

August 15, 2009 Posted by | Game, Game Architecture, Game Engine, Gaming, IBM Rational, Product Engineering, Rational, Rational Unified Process, Software architecture, Uncategorized, Unified Process | Leave a comment

Software architecture

Following are my comments on “if in Building construction Architect requried then why not in Software development?” in International Association of Software Architects group in Linkedin

Great to see an healthy progress of discussion.

I agree with much of views expressed above:
1. Business planning role as a Technical role: Yes, Software is intended to serve a business purpose, and therefore, architect has to balance between business and technical perspectives
2. In constructing a typical 1-storey brick house, you wont need an architect, but not true for a complex of mixed-use structures: Yes, trivial constructions doenot require an architect (though it requires someone to know and decide that what is being constructed is trivial). However, when trivial construction go on to serve larger business cause, that would call for an architect (depending on size and nature of work-involved) to decide whether that could be achieved. It is yet another matter, whether these decisions are made by someone designated as xyzArchitect or by someone who plays that role as an overloaded function
3. Foresight matters: Yes, architect should have foresight (and use as much techniques to enhance it as well) as much as humanly possible
4. Frequent changes in requirements: Yes, Architect has to work with frequent changes in requirements, and decide what should be done from the list of what can done
5. Cares about the quality, and who has a broad vision: Yes, architect should care about quality as product is serving a business and social purpose
6. Ability, knowledge and expertise to go through all phases of SDLC: Yes, to be effective, architect should have knowledge and expertise in all phases of SDLC to balance interests which are, at times, in conflict with some others
7. A Software architect is NOT a Deity or any other form of holy entity to be worshiped: Yes, software architect is a role accountable to business. Again, software architect is not infallible, and can only try and balance the conflicting interests powered by his skills, knowledge and experience
8. Old and time-valued profession when it comes to construction: Yes, we are young as industry but it is great that we have explicitly realized the importance of architecture early on. That should give us late entrant advantage of learning from others
9. We have not had enough amount of accumulated software mistakes: I believe, being pervasive (meaning that software is everywhere and influencing every business/life), it is very important that we initiate task of accumulating software mistakes and learning from such mistakes.

February 7, 2009 Posted by | Software architecture, Uncategorized | Leave a comment

Business, and Software Architecture

Following are my comments on “This is our chance – how we pitch architecture value to the masses” in International Association of Software Architects group in Linkedin

Business requires and would demand value now and value later, and shrinking time line is a force (like many other) that architect needs to negotiate and balance. Architecture, as a subject of study and profession, is of no practical relevance unless it is translated into tangible value in the context of current and future business realities.

I believe, architecture continues to be relevant. Architects need to identify the value in concrete terms and communicate to other stakeholders, to be relevant

January 9, 2009 Posted by | Product Engineering, Software architecture, software engineering, Uncategorized | Leave a comment