Software Engineering weblog

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

As per IEEE definition, software engineering is “systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software”. There is still ongoing debates on how much engineering can apply to software development, and what would applying engineering mean.

Let us put it this way. Being “systematic, disciplined, quantifiable” is more of a business need. As software is getting increasingly pervasive to every aspect of life, business wants software development to be more repeatable and predictable.

Computing, business and software development environment has been undergoing drastic changes. We have attained some level of repeatability and predictability in software development though that may be far below the level desirable from business standpoint. This was due to untiring efforts of many great brains.

Looking back, what helps us towards being “systematic, disciplined, quantifiable”? “repeatable and predictable”?

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

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.

There have been many discussions in the past on whether software development is an art, craft, science or engineering. For convenience, I am listing below the major ones that had profound influence on my thoughts over years

My view is that software development is a combination of all of above. My view is also that software is a construction of human mind or rather minds; and should I say human brains. Yes, mind and brain. Emotion and intellect. What is important to me is this human creation has pervaded virtually every aspect of life and business by now, unlike any other human creation, and hence business critical.

It is an art, it is a craft… beyond all that business depends on it; life and career of many depends on it. Hence, it is important to bring in continually better control, better quality, better transparency and better predictability into software development. Taking recourse to engineering is to this end. Engineering is not an end in itself but a means to an end. Engineering as a manager’s tool to have better control, better quality, better transparency and better predictability. From that standpoint, we find that apparently conflicting perspectives are not truly conflicting; they are different dimensions of software development.

Every successful software development manager knows this and manages his/her business accordingly. These fits into my overall management-engineering framework; result of applying learning into practice, and continually refining my learning based on observation.

Is it a right thing to do? There are pros and cons to the argument. Can we development software with a predefined process? Is software development process prescriptive or adaptive? It is very project specific question. There are software development projects which are very mundane and There are ones which are highly complex, and exploratory. There are simple ones where one could go very light and instinctive; small team, developers with good skills, great motivation, and synergy. In a well managed projects, even the latter ones tend to get predictable and prescriptive over a period of time. It is always a project specific judicious mix.

Where we successful? Yes, to some extent. Sure, there were many stumbling blocks. I value the initial commitment to engineering irrespective of whether one agrees to engineering approach to software development or not. Even such a discussion can take place only in the context of related learning from the practical adoption.

I am tempted to explore possibilities of engineering game development, on similar lines and learning from the mistakes of past.

I have always looked at any change with simplicity as a yardstick, and that has helped all through. Any new change must be simple, because my business is delivering solution to my customer on time and budget; not learning technology, tools, standards or best practices, though they are of value as enablers. Indeed, enablers must be simple

Technology, tools, process, standards and best practices that you adopt must be simple to understand, adopt and use. If not, you have a problem in hand, for now and for ever. That is because software is developed by the team, not just an individual, and that team is bound to change over time. If what you are adopting is complex, you would need to get your team up to speed now and every time a new member comes in. Again, technology, tools, process, standards and best practices are bound to evolve. Tracking these, and ensuring that entire team is in sync, is a greater challenge. My experience is that these are not complex, in itself. Issue is made complex, by a myopic vision or dogmatic mindset.

My advice is: Keep it simple, always. Life is simple. Let us not make it complex

Well, I am an agile practitioner and consultant. I have seen right and wrong practices. I have listed some of them in my earlier blogs.

To me, agile was a corrective approach to process overdrive to ensure quality. Ironically, in process overdrive, customer, people and quality took backseat behind defined process and dead documentation.

Going by this lecture, and many wrong agile adoptions that I have seen and objected to, it seems agile is headed towards a similar destiny, unfortunately.

Issue often is focus is shifted to methodology, buzzwords and practices rather than more fundamental factors like value to customer, motivation and skills of people, commitment of the team (which includes customers, users and management), continuous correction.

Process, standards, being agile, automation etc were introduced as a silver bullet. Let us not forget that they are essentially people enablers. If people are forgotten, if team is forgotten, if customer is forgotten, if user is forgotten, do not blame the process, standard, methodology, or tool. Please understand that it is now time to retrospect and introspect.

One does not adopt knowledge base and process framework. Rather, you pick and choose from it. I agree, “extract any element of RUP you think you need on a given project and add it to Scrum”, as pointed out by Richard, is the right way to use it. Meaning, in that case you are using RUP as a reference, and not as a textbook or bible. Again, you need not worry about size of encyclopedia if you know what you need from that

Again, I believe, good architecture and design is important for software development and role of architect, for me, is in war front (and therefor, hands on and continuous; again in sync with RUP), and not in the control room. Such architecturally-orientation is not in conflict with agile practices. In my understanding, what agile practices stand for is ‘right sized” architecture or design, rather than discounting their value.

Incidentally, I do not ask my customers to adopt RUP but I present to them as a knowledge base only. I also use it as a knowledge base, at the back of my mind, in my consulting service.

I would like to hear from you on your thoughts and on what you find in as conflicting

About

Software engineer referred here is not a person with designation “software engineer” or similar but a practitioner in perpetual quest in balancing academic interest with business priorities.

This is blog of my forays into software engineering!! Indeed, software engineering is not new; it is there for decades now… to be precise, since NATO conference 1968. But does it make sense? does it have practical relevance? in the context of business imperatives? what does practical adoption involve? … and many more questions follow

In my business, my endeavor to deliver business success to my customers leveraging software engineering principles, best practices, tools, technology and so on… and my learning and experiences are what I seek to share here