Sunday, November 24, 2019

Emergent Architecture is not a thing

Emergent architecture is a term I heard for the first time from a coworker a while ago. It was touted as a combination of agile and architecture, or perhaps as the way the shiny term "architecture" was inserted into something as face paced as Scrum, or as a way for the company justify not having architects, but to put it plainly, it's not a thing.

There are a few things wrong with it... conceptually. 

I have read a lot about it, looking for any source of information I could, presentations, blogs, some links here and there, and I could not find a solid base for what they claimed it was, or any reason for it to be claimed as a thing, except for the need to name something with "architecture" on it.

Agile is a methodology, Scrum is a method, if you want to know a bit more about the difference just hit Wikipedia. They are related to how to build software.  Now, architecture, is about structure, is about what you build. You can reach that structure with any method, the structure itself is not part of the method, much less the methodology.  Since:
  • Agile is about process
  • Architecture is about structure
Then, conceptually, it makes no sense to name or classify any architecture as a type of process.

Then why the fuss about it?

You can read the term by many people in the sales part of Agile couching, classes, books, certifications and trainers. They use it because is a shiny term, and we all love shiny terms (Agile itself is a shiny term).

It also comes as a need to solve (or give the appearance of solving) one of the big problems in Agile: technical debt.

Technical debt...

Don't get me wrong, I use agile every single day, I am a defender and I really see the potential, but:
Like many methods that focus on delivering "value" to business first, code later. Scrum in particular (to pick one) lacks anything related to architecture, if you are iterating delivering something piece by piece to the customer, for "value", then you most likely are sacrificing a better structure, tool set or design (architecture).

That's why after a few months, you have a big backlog of things you would like to do, but the "business" does not consider it important. Should I move to RabbitMQ now? Should I use MongoDB instead of SQL? Oh... I need a configuration service! Too late now. Too expensive to change.

But thinking ahead is a bit contradictory with Scrum (no Big Up-Front Anything)

The big mistake: assuming change is cheap.

Building the minimum, they say:
"So as we evolve the system, we build only enough architecture and design to support the functional and nonfunctional requirements that we are focusing on for that Sprint [sic]". - PracticeAgile.com [1]

The pillar all these pseudo-not-architecture ideas are based on, is one that reads "Assumes change is cheap" (or a variation of this quote). This is plainly a lie, you cannot assume change is cheap, everything about software have proved us that change is not cheap [2].

The Agile concept that we must not do Big Design Up-Front (a la waterfall) is a good one, but that should not be confused with avoiding a good design from the beginning. You can't change from a monolith to microservices after 50% of the software is up, you can't easily (cheaply) change from a pull-model to event-based architecture after you deployed because you can't scale. These decisions should have been made before.

Architecture should come before code

As part of any solution, you need to know what you are going to build. This does not mean you will do a full waterfall-like planning with tons of pages of documentation and hour estimates and work statements, no, it means you have to plan (blueprint) what is that you are going to build. Then, you can use any method for that.

You must be as frugal as possible without sacrificing quality. Some mock-ups, physical and logical architecture, domains, patterns to be used, basic system interactions, security considerations, performance considerations, tool set, tech ops and dev ops, coding guidelines, etc.

But I don't think that deserves a new name :) 

You just need to do it right, as early as possible, because paraphrasing Meyer, "refactored garbage is still garbage" [3]

Resources:
[1] Practice Agile: https://practiceagile.com/emergent-architecture-handled-agile/
[2] OOSC, Bertrand Meyer
[3] Agile, the good, the Hype and the Ugly, Meyer 


Sunday, July 14, 2019

NET Core, Java and Open Source

We need to talk about it

How open is .NET Core and C#? How does it compare to a platform like Java? Well... let's see.
Disclaimer: The post is a resumed version with lots of links, so be prepared to read it in a DFS or BFS way :) 

.NET Core

  1. In November 2014, The Microsoft team announced that "NET Core is Open Source"
  2. In 2015, Microsoft releases Visual Studio Code, a cross-platform multi-language IDE. 
  3. All these released under an Open Source license. The MIT License.
  4. NET Core runs in Windows, Linux, Mac and ARM-based systems (IoT)

Java

  1. Originally made open source by Sun in 2006
  2. Released under GPLv2 CE license. The CE clause allows it to be used in a more restrictive scenario. 
  3. Oracle has a different licensing schema for "Enterprise Java". While the OpenJDK is still safe (and should remain so) Enterprise customers face a different problem.
  4. It was conceived also as cross-platform and has wide support and a huge knowledge base.

Similarities

  1. They are both open source and cross-platform frameworks.
  2. Java and C# as languages are both Object Oriented and depending on whom you ask, kind of similar.

Differences

  1. Licensing: The MIT License is less restrictive than GPLv2 CE. If this could or could not be construed as meaning "more open" we will need a lawyer to find out. But general consensus is that The MIT License is less restrictive.
  2. Simplicity of Licensing: NET Core does not have nor requires a different "Enterprise" license. This simplifies licensing model from development to production.
  3. NET Core is a bit more than just C#, is includes VB and F#.

Bottom line

Where your preferences take you to pick one or the other due to technical or community differences, rest assured that using .NET Core will be at the least as safe (from an Open Source licensing point of view) as using Java. 
So... what are you waiting for? dotnet new something...