2DV603 – Software Design
Reflections on : No Silver Bullet: Essence and Accidents in Software Engineering
The 1986 paper by Frederick P. Brooks, “No Silver Bullet: Essence and Accidents in Software
Engineering,” had a big influence on Software Design and Software Engineers. In his article Brook
has distinguished the essential and accidental problems. He stated that there are not much we can do
about the essential problems because they come from the nature of Software. However, we can
avoid accidental problems. To avoid these problems Brook suggest to develop software with
reusable and modular parts, plan the development incrementally. This ideas of Brook has affected
Software Development in general. It promoted agile development technique, rapid prototyping and
lean development and these approaches getting more popular day by day.
Three Core Problems
Brook mentions several core difficulties on his article. I aim to address 3 of them and come up with
some possible mitigations.
Complexity problem makes software hard to finish on time and budget, test and maintain. So when
I think what can be done to avoid unnecessary complexity, I can say that small, incremental and
iterative development approach can help reduce complexity. Developers can refactor the code after
every iteration to make it simplistic. Conducting tests in every iteration can make the project group
detect possible bugs in earl stages and it can prevent building layers on a buggy ground. It can also
reduce complex testing efforts that needs to perform at the end of the development because most of
the parts is already tested in early iterations. The other mitigation comes in my mind to reduce
complexity is understanding how the business works and simplify the requirement and
specifications. Because, in some cases business owners can be over-complicating their process and
putting lots of unnecessary requirements. Putting some effort on understanding the real needs and
requirements of the business might help to reduce complexity.
Not like cars and building software in theory is easy to change. That makes pressure on software
teams to maintain and adapt on this changes. One solutions to make change process easier can be
designing the software with modular components. With this way, when a change is needed, a
change in a component might have minimum effect on other working parts of the software. So there
would be less need to change whole working system. One other way to be prepared for changes can
be building the software on a small core that can tolerate changes with less side effects.
Conformity is the fact that new software must conform the way that things done in the past. New
software should conform old environments, hardwares etc. We can solve this problems by using
interfaces to conform old systems. So that we don’t need to design according to old systems but we
can still be compatible with them. One other solution might to follow certain standards and
protocols to conform most of the existing systems that follows same protocols.
Reflections on the Design of Design Essays (1-3)
In the first chapter Brooks states that we can learn from the experiences gained in other disciplines
and apply them in another. Although, we may not be able to talk about specification we can still
learn about problem solving and design process. In my opinion, if we consider design as an
independent process, we can learn a lot from other domains where design process also conducted.
2DV603 – Software Design
Moreover, it can give us different insights and widen our view. In the following sections, writer
discusses about the design concept and what is so important about it. Brook claims that there is a
big value, creating design concepts. Even though these concepts inevitably fall short, they get us
closer to get better implementations. He also mentions about the importance of conceptual integrity.
Tells that a design should be done with uniform concepts conceived by a few minds. Then Brook
discusses about rational design model. Its benefits and limitations. I found Brooks ideas very
convincing and interesting to think on. However, his use of language and style of writing seemed
really heavy for me.
First Problem: We Don’t Really Know the Goal When We Start
In my opinion, this problem mentioned above is most often encountered yet usually unavoidable
problem in software design. In my experience, different stake holders of the project usually have
different insights about the goal of the end product. In the very beginning of the design processes
this understanding gap between stakeholder is even wider. I have experienced this problem last year
when I was working in a project team for an assignment. We used the rapid prototyping approach to
get better understanding of the goal and to minimise risk at the end of the project. Even tough it has
consumed some time, it really helped us to fulfil our requirements and specifications. It also helped
us and other stake holders to decide what we were really want.
Second problem: The Constraints Keep Changing
In todays world, like everything, our constrains in software production process changes. It also
happened to our assignment group which I mentioned above. We have asked to the teachers if can
we use one particular library for our project but got a no as answer. After few weeks, we started to
write our own solution instead of this library. However, after a while teachers decided that we could
use that library. We decided not to change our own design because even if the usage of this library
would save some time if we would change our software’s design accordingly it would cost us more
time. So we decided to stick with our design and write our own solution rather than using this