The concept of a piece of software can be boiled down to 3
related concepts: data, the relationship between those two pieces of data and
the algorithms/functions used to process the data. As the complexity goes up so
do the issues that can arise from modifications in code to do new functions. They
can adversely affect other pieces to the program. Having multiple developers
and storage locations for code can also greatly impact productiveness. The No
Silver Bullet article states there is not one single development that can
provide “even one order-of-magnitude” of improvement in software engineering. Google
has tried to resolve some of this by having a “monolithic” codebase. The
advantages of this are extensive code sharing and reuse. This cuts down on time
spent creating a piece of software. Allowing them to focus more time on the
more complex tasks.
This also is brought up in the Kode Vicious response to
cherry picking. At some point an engineer will realize that they will be better
off spending their time merging rather than picking out just the parts they
need. By Google having the monolithic codebase, it is all there for everyone to
use. If a team wants to rely on another teams’ code, they can do so directly.
Instead of picking through another repository and spending time bring over, it’s
already there for the taking. I believe Google has come very close into
creating a “silver bullet” for their ideals in software engineering. There are
issues with this structure. It creates greater overhead cost in hardware and
maintaining code. One way other software engineers have tried to manage the maintenance
issue is with the use of distributed version control systems like Git. Google
has started using Git for its Android and Chrome teams because of their
collaborations with outside partners.
The silver bullet Google has created is more of a shotgun
shell in that it uses many smaller pieces to solve larger problems. Other early
breakthroughs like high-level languages have allowed more complex problems to
be solved. But with those high-level languages has come a greater dependence on
them. It seems technology is always advancing and resolving current issues.
Then as those issues are resolved, even more complex issues will follow. It is
a never ending cycle. There will always remain the issue of verifying and
testing new software. The methods to test vary just as much as the methods that
could have been used to solve them. The documentation for which also takes time
but is a crucial part of software engineering.