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”?
I would classify progresses into following categories, with progress made in each of them:
1. Processes (who does what and when) and methods (how)
2. Standards (with standards like CMMI levels on one side of the spectrum and coding standards at the other side)
3. Proven practices (Harvest success patterns)
4. Tools (Software tools that help us do our work better and faster)
5. Metrics (Measures helping in objective observation and decision making)
6. Body of knowledge
7. Code of ethics
These are what I am calling elements of engineering discipline.
Let us not have any illusions.
Methodology/process wars are far from over. Proliferation of programming languages would continue. Computing technologies would continue to evolve.
There is a long way to go before software engineering would stabilize as a true engineering discipline but essential ingredients are getting to be in place and there is business need…
Let us move on…
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.
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
1. Book Software Craftsmanship – The New Imperative
2. From Craft to Science Part 1 and Part 2
3. The great art and craft of software development
4. Software engineering and the Art of Design
5. The art, science and engineering of software development
6. Manifesto of software craftsmanship
7. The privilege and responsibility of software development
9. What is software design?
10. Software that lasts 200 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.
When I look at game development, as a software engineer, is a striking similarity to what we have gone through in software development.
Most critical milestone was awareness of software crisis and decision to adopt an engineering approach to software development. That essentially meant applying principles and practice of engineering into software development.
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.
Life of a software engineer was rather simple, unusually simple with adoption of agile approaches; or so it seemed. Clouds seem to be coming back, and turbulence is back in the air
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
Great many ideas eventually degenerate into management fads or buzzwords being used indiscriminately. Latest in the list seems to be agile.
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.
Following are my comments on “What’s your opinion? Which is best? RUP, Scrum, or XP?” in Agile Alliance group in Linkedin
Why not RUP and …? RUP is a process framework/knowledge base and not a prescriptive process. You rather use RUP to derive a process instance
Great to see the active and healthy discussion and hope to see this progressing further.
In this context, I would like to reiterate and substantiate my statement that RUP is not a process but rather a knowledge base and process framework. Lists of activities, relative order in which they should be performed, which artifacts to create, and dependency between them are more of guidelines/reference, and not meant to be prescriptions. Interesting links to read in this line would be: http://www.agilealliance.org/system/article/file/941/file.pdf and http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan03/StoryOfRUPManager_TheRationalEdge_Jan2003.pdf . There are many more but I hope these links clarifies
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