[Info-vax] Coding with/without RDBMS

[Arne Vajhøj]

On 10/19/2021 12:34 PM, Bill Gunshannon wrote:
> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>> On 10/18/2021 1:28 PM, Simon Clubley wrote:
>>> OOP allows you to very nicely implement abstraction layers provided
>>> you don't go overboard and have 10 layers of abstraction to write
>>> out a single character (for example). :-)
>>>
>>> Agile OTOH seems way too often to be used as an excuse to not to do
>>> the hard and real work of designing and laying out the overall
>>> architecture before implementing the design.
>>
>> I think that is mostly a myth that thrives among non-agile
>> developers.
> 
> Nope, it's accurate.

First let us document that agile do use architecture.

The Open Group (same that do the Unix specification and TOGAF) has
create Open Agile Architecture Standard:

https://pubs.opengroup.org/architecture/o-aa-standard/

Plenty of key agile people have been writing about agile and
architecture:

Jim Highsmith (co-author agile manifest) in "Architects: Anchors or
Accelerators to Organizational Agility?" presenttaion:

"So, Are architecture and agile development compatible?
Of course they are!"

Robert Martin (co-author agile manifest) in "Agile Principles, Patterns,
and Practices in C#":

"This is not an abandonment of architecture and design. Rather, it is a
way to incrementally evolve the most appropriate architecture and design
for the system. It is also a way to keep that design and architecture
appropriate as the system grows and evolves over time. Agile development
makes the process of design and architecture continous."

Martin Fowler (co-author agile manifest) in
https://martinfowler.com/articles/designDead.html:

"I think there is a role for a broad starting point architecture. Such
things as stating early on how to layer the application, how you'll
interact with the database (if you need one), what approach to use to
handle the web server."

"So my advice is to begin by assessing what the likely architecture is.
If you see a large amount of data with multiple users, go ahead and use
a database from day 1. If you see complex business logic, put in a
domain model. However in deference to the gods of YAGNI, when in doubt
err on the side of simplicity. Also be ready to simplify your
architecture as soon as you see that part of the architecture isn't
adding anything."

Kent Beck (co-author agile manifest, inventor of XP) in
"Extreme Programming Explained":

"The architecture for a little system should not be the same as for a
big system. While the system is little the architect makes sure the
system has the right little architecture. As the system grows, the
architect makes the architecture keeps pace."

Alistair Cockburn (co-author agile manifest) in "Agile Software 
Development":

"Agile methodologies place a premium on
getting something up and running early, and
evolving it over time. Not all projects are equally
amenable to tiny evolutionary steps. Deciding how
to break up the giant architecture on a large project
into smaller pieces that can be built and tested
incrementally, does take some work. It can be
done, however, and is worth the effort."

"We insist that the architecture be allowed to
adjust over time, just as the requirements and
process are. An architecture locked down too hard,
too early, will not be able to adjust to the inevitable
surprises that surface during implementation and
with changing requirements. An architecture that
grows in steps can follow the changing knowledge
of the team and the changing wishes of the user
community."

Scott Ambler (inventor Disciplined Agile Delivery) in
http://agilemodeling.com/essays/agileArchitecture.htm"

"Contrary to popular belief, architecture is an important aspect of
agile software development efforts, just like traditional efforts, and
is a critical part of scaling agile approaches to meet the real-world
needs of modern organizations. But, agilists approach architecture a bit
differently than traditionalists do."

"Architecture provides the foundation from which systems are built and
an architectural model defines the vision on which your architecture is
based. The scope of architecture can be that of a single application, of
a family of applications, for an organization, or for an infrastructure
such as the Internet that is shared by many organizations. Regardless of
the scope, my experience is that you can take an agile approach to the
modeling, development, and evolution of an architecture."

These people know what agile is, because they invented agile!

Anyone believing that agile does not use architecture has not studied agile.

Obviously not everyone has studied agile. And in theory the belief
could thrive both among pro-agile and con-agile people. But I do
not think I have ever met the belief among pro-agile.

It is a belief that thrive among con-agile that have not studied
agile.

>> Agile does not mean no architecture. Agile means the
>> right amount of architecture depending on project
>> size, criticality and volatility.
>>
>> There has been written a ton about it the last decade.
>> Leading authors include Scott Ambler and Martin Fowler.
>> Some agile methodologies even use TOGAF.
> 
> One of the places I worked at made us all take Agile clases.
> I still have my book from the course and I break it out when
> I need a good laugh.  It talks about what is now called
> "waterfall" (we didn't call it that when we were doing it)
> as something totally foreign to what was actually done.
> And then sets itself up as the answer for a problem that
> exists only in the minds of Agile supporters.

The term "waterfall" to describe software methodology has been
used since at least 1976 (by a couple of military vendor guys
in a paper presented at an IEEE conference).

But let me guess: they explained that with waterfall then if
any requirements changed then all work was ditched and started
over.

Just like con-agile often do not have a clue about how agile
works, then many con-waterfall does not have a clue about
how waterfall works.

Arne