Well, for those of you who design and build lots of software or calculate projects with methods like Function Point Analysis, it's probably not a suprise but to me, creating some serious software since a long time, it was an awful discovery (again) that (too) much of my coding was about errors and warnings. I mean avoiding errors about security, technology and user behaviour and some other non-functional categories too. A quick count of lines of code revealed that more than 30% was not directly related to the functionality I wanted to create. Wow, that is a waste! .
And, it's not only the waste of time, creativity and labour effort, but all that "unnecessary" code wastes a lot of energy too. Amazing !!! ... Imagine we could spend all that brain and natural resource power to support and growth of humanity and nature. There would be no American quarrel between the GOP and Democrats about their deficit and spending. No European fuzz about Greece and other countries to save the Euro. Perhaps even the more serious problems of our world about hunger, health and human rights (H3) would be more "solvable".
If designing and building software and systems was a simple and repeating task, we would have it more automated than it is today. Of course over time we’ve learned how to standardize various aspects of software engineering, both in process and in architecture, business and technology. However, it is still a profession where a lot of pure craftsmanship is needed with a steep learning curve on the job. Mainly because of the variations and necessary differences in technology and business requirements. Why? Well, because if let’s say all CRM systems (and their implementations) of all companies were the same, there would be little distinction between the customer handling of those companies and therefor little possibilities to beat each other in competition. Handling those variations and creating an innovative environment to build something that makes a difference, demands creativity. Teams where this atmosphere is cultivated, can come up with superior results.
but . . .
As already explained with the “Technical Excellence” issue, a lot of people are unfortunately not that good. Yet . Only heavy investment in education and an atmosphere of learning on the job, with all consequences including the financial ones, can solve this. Remember, people do learn a lot from each other as long as they are given the opportunity and repsonsibility to do that.
so . . .
Give teams the mandate to organize their own processes and results. Give them a challenge only like: "Come up with something we can really beat the competition with.". Of course, some constraints are useful but better support them with attention, leadership and resources (standards, time, money, expertise, ...).
"Think big, act small, fail fast; learn rapidly" is the famous pitch out of the book "Lean Software Development" of Mary and Tom Poppendieck (2003). Very often quoted and more often misunderstood or badly implemented. Agile software development is often embraced as a method (like SCRUM, XP, SMART, DSDM, OPEN-UP, IAD, etc.) to avoid the traditional "hard work" to properly design and document the solution before building it but instead "learn on the fly".
Well, one of its valuable characteristics of an agile process is indeed the qualitative growth of the team and their work due to advancing insight by test software early and implement it fast. However, that does not mean "fire at will" with some ideas originating from the latest technology.
"Think big" points to stay close to the issues to address, looking at them as a whole and make sure the business case remains solid.
"Act small" means one should keep the boundaries of the system and the development process crystal clear. Complicated communication with other organizational entities and their applications should be avoided as much as possible despite of the promising benefits (which are usually very hard to get). "Normalizing" your architecture and your processes is maybe challenging but very rewarding at the end of the day.
"Fail fast" should tempt you to test everything you produce as soon and solid as you can. From functional designs to actual code. That includes all integration aspects, both code and deployment aspects. Only a complete solution will address the business case properly.
"Learn rapidly" challenges you to stay close to the changing world. Predict and plan the future but establish the accompanying measurements and respond accordingly. And make sure architecture and code is change tolerant. All above issues are more behavioral than a cookbook of activities to follow carefully. The latter is just conditional to make sure people can focus on the real things of software development: improvement, change and innovation. Evaluating both process and built software regularly should keep the future paths clean. "Inspect and adapt".
but . . .
Reflection and gathering lessons learned simply takes time and there are often a lot of other priorities. The last 50 years or so in every method evaluation is highly valued but in practice it’s the black sheep of all activities you can think of. One way or another, we just can’t get the business case clear enough. Common sense will tell everybody that lessons learned should be taken seriously to avoid making the same mistakes or making reusability a natural habit but hard data and figures coming from lessons learned are still very hard to get. Even knowledge management systems tend to overgrow themselves making them polluted quickly and less useful in the long run.
so . . .
Well, what can I say? Just don't allwo any process or project to end without a "How can we do it better next time" activity. Some way or another we all prefer to become "firemen". It's great to be in the team where al the action is. But when the fire is under control, everybody starts looking for another fire without asking how the previous one started anyway. It's just mor efun standing on a ladder with a big hose than pouring in black smoking mud to find "something to learn".
One of the naturally achieved goodies of agile processes, is the the focus on the real issues. Often the 80/20 rule (focus on 80% of the functionality with 20% of the effort) or a MoSCoW (Must, Should, Could and Won’t haves) technique is used making sure that the right priorities are set and that exotic exceptions are avoided as much as possible. For the architecture and design in fact the same principles have to be followed.
The more simple and easier to understand the various components of a system are, the faster, cheaper and better is will be built and maintained. “Normalizing” the component architecture, as is developed by Mannaert and Verelst of the University of Antwerpen, might be the ultimate solution. Away with all the complexity of interfaces and dependencies like dominoes which makes quick changes of systems impossible. The result should be a mean-and-lean system with lower construction and production costs, faster ROI and much easier to change.
but . . .
There is a long history both in the developments of business processes and in the technologies as well. Exceptions in business often make the difference (at least users think that way very often) and technology vendors have a tendency to “integrate” everything they have (making in fact the overall architecture more complex). There are a few reasons for this: - Legacy. Tools a built and release after release expanded with maximum backwards compatibility
- Commercial. Despite of the “open software” discussion, it’s of no avail to most large technology vendors to have simple plug-in and replaceable tools. They want client lock-ins for the long term.
- “New Genoa” effect. This means that a technology, process or even idea will just originate somewhere even if a similar alternative is very close by. Just like languages in New Genoa where people speak very different languages with range of only a few miles. It’s quite similar to the “not invented here” syndrome.
so . . .
Please take anoter look at Normalized Systems. It's not only about keeping things simple and focusing on the functionallity you really need. It's also about a paradigm and mindset in software architecture and software process as well. the basic strategy should be: "Everything should be replaceable whenever without consequences for any other component in any system".
In an environment where change is embraced as default, it’s absolute top-priority to focus on a high quality and stable architecture. On top of that, deep knowledge and experience with the technologies involved is mandatory. There is little room to just experiment with new tools for systems that have to go into production within a couple of weeks. Nevertheless, new technologies will offer new business opportunities to chase after. Additionally, badly designed and built software is a hazard for future change. And there will be a lot of change.
but . . .
This is easier said then done. In fact this is the underlying problem why in general agile processes are not that widely spread as one would want or expect. People just have to be better than we’re used to. In a waterfall/predictive situation there are more singular specialities where a production planner of project leader can work with. In an agile environment there is a lot more pressure on everybody to be adaptive in the functions or roles, if there are any. People have to be specialized generalist, communicative, collaborative, technically educated, business aware and experienced. Let’s be honest. In practice not many people are that good and the environment is not willing or aware enough to invest enough to make people that good.
so . . .
It's simple. If your team is not this good you only have two options: either you have to make them better a invest seriously into the people (and allow the accompanying learning curve) or don't dive into agile software developement. Agile is not a substitute for failed predictive methodologies. Again, agile is not a methodology at all. It's a way of living and people have to be able to cope with every aspect of this new life.
.
If designing and building software and systems was a simple and repeating task, we would have it more automated than it is today. Of course over time we’ve learned how to standardize various aspects of software engineering, both in process and in architecture, business and technology. However, it is still a profession where a lot of pure craftsmanship is needed with a steep learning curve on the job. Mainly because of the variations and necessary differences in technology and business requirements. Why? Well, because if let’s say all CRM systems (and their implementations) of all companies were the same, there would be little distinction between the customer handling of those companies and therefor little possibilities to beat each other in competition. Handling those variations and creating an innovative environment to build something that makes a difference, demands creativity. Teams where this atmosphere is cultivated, can come up with superior results.
. Only heavy investment in education and an atmosphere of learning on the job, with all consequences including the financial ones, can solve this. Remember, people do learn a lot from each other as long as they are given the opportunity and repsonsibility to do that.
"Think big, act small, fail fast; learn rapidly" is the famous pitch out of the book "Lean Software Development" of Mary and Tom Poppendieck (2003). Very often quoted and more often misunderstood or badly implemented. Agile software development is often embraced as a method (like SCRUM, XP, SMART, DSDM, OPEN-UP, IAD, etc.) to avoid the traditional "hard work" to properly design and document the solution before building it but instead "learn on the fly".
One of the naturally achieved goodies of agile processes, is the the focus on the real issues. Often the 80/20 rule (focus on 80% of the functionality with 20% of the effort) or a MoSCoW (Must, Should, Could and Won’t haves) technique is used making sure that the right priorities are set and that exotic exceptions are avoided as much as possible. For the architecture and design in fact the same principles have to be followed.
In an environment where change is embraced as default, it’s absolute top-priority to focus on a high quality and stable architecture. On top of that, deep knowledge and experience with the technologies involved is mandatory. There is little room to just experiment with new tools for systems that have to go into production within a couple of weeks. Nevertheless, new technologies will offer new business opportunities to chase after. Additionally, badly designed and built software is a hazard for future change. And there will be a lot of change.
