tagged by: evolutionary design

Is Design Dead?

For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.

Evolutionary Database Design

Over the last decade we've developed and refined a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems, in green field projects as well as legacy systems.

by Pramod Sadalage and Martin Fowler

May 2016

Read more…

article

agile refactoring application architecture database evolutionary design

Schemaless Data Structures

In recent years, there's been an increasing amount of talk about the advantages of schemaless data. Being schemaless is one of the main reasons for interest in NoSQL databases. But there are many subtleties involved in schemalessness, both with respect to databases and in-memory data structures. These subtleties are present both in the meaning of schemaless and in the advantages and disadvantages of using a schemaless approach.

Foreword to Building Evolutionary Architectures

Recently my colleagues: Neal Ford, Rebecca Parsons, and Pat Kua, wrote a book entitled "Building Evolutionary Architectures". I was honored that they asked me to write the foreword.

Abundant Mutation

Any reader of my writings will know that I'm a big proponent of evolutionary design. Despite my enthusiasm for this approach, no technique is perfect and I'm just as happy to report its problems as I am its successes.

by Martin Fowler

14 Feb 2005

Read more…

bliki

evolutionary design technical leadership

Asset Capture

Asset capture is a strategy for developing a StranglerFigApplication. You can think of many applications as managing a key set of assets. A payroll system looks after employees, a trading system looks after trades, a leasing system looks after leases. To gradually cut over to a new system, you can begin by identifying a subset of assets that you'll start with the new system. Often the best assets to start with are either simple assets (because they are quick to get going) or those that have needs that are particularly difficult to handle with the old system.

by Martin Fowler

29 Jun 2004

Read more…

bliki

evolutionary design legacy rehab

Design Stamina Hypothesis

Is it worth the effort to design software well?

Evolutionary S O A

Can SOA be done with an agile approach?

by Martin Fowler

12 Sep 2008

Read more…

bliki

application integration evolutionary design

Monolith First

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .

by Martin Fowler

3 Jun 2015

Read more…

bliki

evolutionary design microservices

No DBA

In many organizations, it's expected that any persistent data will be stored in relational databases that are managed by a central database management group. There are various reasons for such central control, usually centered around using IntegrationDatabases. Central data groups worry about keeping out malformed data, queries that can slow down important shared resources, and consistent data models across the enterprise.

Worthy these aims may be, but one consequence of them is considerable ceremony about storing data. I often hear complaints about change orders that take weeks to add a column to a database. For modern application developers, used to short-cycle evolutionary design, such ceremony is too slow, not to mention too annoying.

So application development groups tell me of using NoSQL databases to do an end-run around the DBAs. It helps that they are using a "mere datastore" here, not a "proper database". That way the DBAs can be kept out of the loop, often not told or happy to not care.

by Martin Fowler

25 Feb 2013

Read more…

bliki

database noSQL evolutionary design

Parallel Change

Making a change to an interface that impacts all its consumers requires two thinking modes: implementing the change itself, and then updating all its usages. This can be hard when you try to do both at the same time, especially if the change is on a PublishedInterface with multiple or external clients.

Parallel change, also known as expand and contract, is a pattern to implement backward-incompatible changes to an interface in a safe manner, by breaking the change into three distinct phases: expand, migrate, and contract.

by Danilo Sato

13 May 2014

Read more…

bliki

evolutionary design API design refactoring

Sacrificial Architecture

You're sitting in a meeting, contemplating the code that your team has been working on for the last couple of years. You've come to the decision that the best thing you can do now is to throw away all that code, and rebuild on a totally new architecture. How does that make you feel about that doomed code, about the time you spent working on it, about the decisions you made all that time ago?

Seedwork

In the very earliest days of Object-Orientation, the OO advocates like me put a lot of attention into arguing in favor of reuse. Early on we talked about reusing of classes. Then we discovered that reusing individual classes, while it worked in some cases, didn't work so well elsewhere. So we got into reusable frameworks, which got us part-built applications of functionality.

by Martin Fowler

11 Sep 2003

Read more…

bliki

evolutionary design

Tolerant Reader

One of the benefits of using web services is that it helps you to decouple various parts of a system. People can work on separate code-bases with some degree of separation. Although you get some decoupling, you cannot eliminate the coupling completely because the services still have to communicate to each other through their interfaces. The sad thing is that many teams make this coupling much worse than it should be.

by Martin Fowler

9 May 2011

Read more…

bliki

application integration evolutionary design

Yagni

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".


All tags

API design · agile · agile adoption · analysis patterns · application architecture · application integration · bad things · big data · board games · build scripting · certification · collaboration · computer history · conference panels · conferences · continuous delivery · database · design · dictionary · distributed computing magazine · diversions · diversity · documentation · domain driven design · domain specific language · domestic · encapsulation · enterprise architecture · estimation · event architectures · evolutionary design · experience reports · expositional architectures · extreme programming · front-end · gadgets · ieeeSoftware · infodecks · internet culture · interviews · language feature · language workbench · lean · legacy rehab · legal · metrics · microservices · mobile · noSQL · object collaboration design · parser generators · photography · podcast · popular · presentation technique · privacy · process theory · productivity · programming platforms · programming style · project planning · recruiting · refactoring · refactoring boundary · requirements analysis · ruby · security · talk videos · team environment · team organization · technical debt · technical leadership · test categories · testing · thoughtworks · tools · travel · uml · version control · web development · web services · website · writing

2019 · 2018 · 2017 · 2016 · 2015 · 2014 · 2013 · 2012 · 2011 · 2010 · 2009 · 2008 · 2007 · 2006 · 2005 · 2004 · 2003 · 2002 · 2001 · 2000 · 1999 · 1998 · 1997 · 1996

All Content