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 method
  • 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]". - [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]

[1] Practice 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)


  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.


  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.


  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...

Wednesday, September 19, 2018

The distributed monolith antipattern

The words distributed and monolith are usually adversaries in software architecture, contrary to the monolith model,  a distributed approach will allow you to have isolated services as building blocks of functionality for your system. Let's assume you reached that architecture already, either from scratch or by decomposing an existing monolith. At this point you have a set of services. 

Some people go and just say - "it's microservices!". Well..., that's not enough yet, but now you have all the pieces into individual services and the whole system working together.  This is a step into the right direction for scalability, but we can do more in other areas. 

So, let's check: how do you deploy them?

If you deploy all services at once, you still have a lot to improve, for now you have a "distributed monolith" (Open to a better name for this), which I consider to be an antipattern, and this is more of a common practice than expected, this is basically a problem inherited from Service Oriented Architecture but there are a few reasons it happens.

Common reasons

1. Services share the same database.
This is old as time, it's OK for this to happen during transition from monolith or classic SOA to microservices, but you need to move away from it. Sometimes organizations just don't pour resources to continue moving forward with the evolution of a system.

2. Deployment constraints tying them together
Some DevOps limitation, rule or result of laziness (e.g. somebody liked how things looked in one docker compose file and left it like that).  

3. Shared library with business logic
Another bad practice from SOA, a developer encapsulated business logic into a library, then new business updates require all apps and services to be updated and deployed almost simultaneously.  Reusability is important in software but doing it through libraries when using services is a Pandora's box. If you have a service-based architecture, expose business logic only through services.  

You can find almost any reason to justify what could be seen as a bad practice, it's up to you, the developer, to decide how to proceed. For example, sometimes you *have* to share a database because consistency is more important than speed or scalability for a specific application. If a requirement like that exists, then you are already building the correct system and there is no need to modify it just to fit with an architectural schema.  

Monday, January 22, 2018

Playing with strings and performance in C#

A few weeks ago, I was solving a problem at HackerRank and after completing a solution that ran  under 100 milliseconds, the program would still timeout during execution. HackerRank limit is usually 1 second, so something was taking more than 900ms.

It was the strings!

Yes, we know handling strings is costly, but this time there was no way around it.  At the final stage of the problem I had to construct a string over 200k chars long from an array of Boolean values that represented the bits of the number.  

Disclaimer: Strings are slow, mainly because they are immutable. Concatenating two strings, creates a third one and possibly 2 for the garbage collector to pickup.

Looking through the code I noticed I was simply using "+=" instead of StringBuilder.Append method. After using StringBuilder the solution was faster and the submission was approved. It was  fast now, but it got me thinking "how much faster indeed?" which ended with me measuring the performance of concatenating strings, because we always knew StringBuilder was faster than regular operation with strings but I still wanted to see the numbers.

I used C# and tested the same set of examples in NetCore and full .Net Framework. I did not notice any performance differences between the two of them.

What was measured?

I measured 3 ways to concatenate strings, and each of them in reverse mode. Here are the 6 variants:
  • Using the + operator. (str += "1";)
  • Using + operator to insert in front (str = "1"+str)
  • Using string.Concat (str = string.Concat(str,"1"))
  • Using string.Concat to insert in front (str = string.Concat("1",str))
  • Using StringBuilder.Append to add at the end
  • Using StringBuilder.Insert to place in front
Every operation was ran against data sets of multiple lengths, for 10, 20, 30, 40 and 50k characters. The chart below shows the results in milliseconds. 

It was a surprise to see that StringBuilder.Append is not only faster, but appears to be in constant time O(1). Also, to see that the Insert method is for certain sizes slower than other operations, so StringBuilder is not always faster.  

Now if we run the tests for a data set with 100k characters, we get a new surprise: the insert method starts being faster at a bit over 50k chars in length, with the other operations degenerating in performance. 

If you like competitive programming or have an interesting in high performance solutions, make sure to always measure. Do experiments a lot in code and test different scenarios. In my case, I had an array reversed so I walked the array backwards and used the Append method instead of Insert. That was the difference between failing or passing a problem.   

Check the code for StringBuilder at GitHub. The implementation uses string.wstrcpy, while is blazing fast, this is still O(n). 

Sunday, January 14, 2018

New programming book published on Amazon

After a relatively long hiatus as a writer I finally completed a new milestone. I coauthored a programming book and published it on Amazon. I must say I am glad that we finally completed it; while it was a fun and rewarding journey, it was a long one and it took a lot of time, effort and coordination. 

The book is in Spanish, and it's 500+ pages long.

Title: "Empiece a Programar. Un enfoque multiparadigma con C#"
Format: Paperback

The title translates to "Begin programming. A multi-paradigm approach with C#". The book is written in Spanish, not only because all the authors are Cubans, but also because we believe that the Spanish-speaking community deserves a fresh new book; instead of a translated one.

We used C# throughout the book in order to teach programming, and we travel from the simple "Hello World" snippet to arrays, data structures, dynamic programming, recursion, inheritance, SOLID principles, functional programming and concurrency - among other subjects - across 17 chapters.  

Every chapter is loaded with code examples, detailed explanations and images to help the learning process. It's aimed to engineering and/or programming students, and even though the material is tailored for beginners, it can also be useful by more senior developers wanting to deepen their knowledge of programming.  

Here are the links to buy the book:

Tuesday, May 16, 2017

It's not RESTFul, but does it matter?

Quite too often we see discussion about what is and what is not REST, some developers excitedly discuss about REST purity. However, does it actually matter? Do you need that level of "purity"? I personally think that it does not and will try to explain why, although I am already convinced that will fail on my attempt.

REST means REpresentational State Transfer, and while almost everybody will tell you that is not necessarily related to HTTP (and technically isn't), in reality, it is, and that's a fact. So when we apply it to our Web Services, we have our new REST APIs or RESTful APIs mixed with HTTP flavors.

Also consider that they do not conform a protocol, or a specification, is an architectural style. So, technically, they are a set of conventions and guidelines and not an actual set of unbreakable rules (like a protocol).  

But they are great, RESTful, REST-like, almost RESTful APIs are all great. I have been writing and playing with APIs since around 2001, and came all the way from XML and SOAP (from the manual aspx, to asmx, to WCF) and then into JSON and REST , and I love them all. In fact, the only thing I don't like about REST is the people behind it trying to defend it so vehemently  :) But there are some issues I am sure you might have encountered before:
  1. Authentication: Purity zealots say that REST is pure and not HTTP-only, yet they use HTTP headers/cookies for authentication over a RESTful API.. wat?
  2. Sometimes it becomes really hard to do it the REST-style (and RPC-style feels natural) 
  3. The typical verbs are not expressive enough for my API (all real life systems are more complex than CRUDy examples) and this kind of ties to #2.

Rule of thumb: Never stop when they tell you   "it's not RESTful if..."

I found this online, no idea who the author is...

Lets shed some light over these 3 cases: 

Case #1

Authentication against a RESTful service: there should be no discussion, your system architecture will make things easier or harder for you, and your decision can't be to put the "purity" of an architectural style over the consistency, completeness and correctness of your system. I have seen scenarios where cookies bring transparency, and others where a token over query string parameters are a better fit. Don't stop a solution because someone tells you "it's not RESTful if...".  

Case #2  

REST is definitely good, but it is not enough, because not everything is a resource. While the idea of exposing documents, files, resources (nouns) feels natural for a huge amount of cases, you will eventually find a situation where is not natural to expose something as a resource. "Resources" and "Processes" can be really complicated in the enterprise. Think about it, we are translating the logic from our object and methods/functions, to basically one "object", whose status can just be CRUDily accessed. 

The REST-workaround to deal with this kind of issue is to "make it" a resource and then deal with its status. Let's say I have a process that can start/stop/pause/rotate/jump/recharge/sing (is my process, so the actions are whatever I decide :) ). One RESTful way to do this is to expose:

GET http://address/process/status 

as a resource. We could GET the endpoint to query and then perform PUT  with the new status every time:

   //other fields
and then starting, or recharging would imply sending the status over via a POST.

POST http://address/process/status

This does not feel natural, passing back and forth the whole status of a process to start/stop "actions". It might be a RESTy way to do things, but certainly it does not help me on this case. What if we have 100 actions? RPC would be a better option here.

POST http://address/process/<start|stop|pause>

We can do things like:

POST http://address/process/jump?howhigh=20

and we could still query the status by calling in a RESTy way:

GET http://address/process/status

There is no rule against combining them. Just go over you API and improve things as you go. Make things easier for you and the clients of your API. Blindly following guidelines for the sake of it, will yield no reward except suffering. 

Having a well documented API is more important than breaking your head trying to conform to some guidelines.

Case #3

The verbs are not enough. Lets take the data structure of a stack and try to represent it in a REST API:


would be my "stack" resource. The only way to modify a stack is by calling PUSH and POP operations, we don't have those verbs, but we can try and see if they fit our RESTful idea. I also need a COUNT, to know how many items are on the stack, and a PEEK, to read the one on the top without modifying the collection. Care to make this in a restful way?

GET http://address/stack

What should this do? To be RESTful, this should just return the whole stack, which is not very useful for what you typically want a stack (could apply same logic to a "queue"). And would be a terrible way to get the COUNT, and I really want the O(1)  order of some operations over a stack.  

POST http://address/stack

This could be our PUSH, sending an object to the top of the stack. What about POP?

DELETE http://address/stack

This makes no sense, because we are not deleting the stack itself. Then even something like /stack/top, would also be incorrect, since the element at that URI would be different after a delete, and finally because DELETE must be idempotent. 

Then what? POST? We already used it. Once you reach this point, is better if we just go back RPC again.

GET http://address/stack/count  (COUNT)
GET http://address/stack/top    (PEEK)
POST http://address/stack/push  (PUSH)
POST http://address/stack/pop   (POP)

POP would "modify" the stack, so, a POST is the catch-all verb to use here. DELETE wont do it and PUT even less, they are both idempotent. 

All these can be also applied to a queue, a circular queue or many other data structures. The verbs might not be enough to support your operations from a semantic point of view, and URIs might not be unequivocally representing a resource. /stack/top, its not a permanent URI for "the element" on the top, is the address of the "top of the stack", the element itself can and will vary over time.

I have a hard time trying to understand how RESTful could be a silver bullet without the ability to represent the most simple of structures. REST and CRUD-style is not enough for everything out there.

Tuesday, May 17, 2016

JustMock and "Failed to initialize coreCLR" on RC2

Unable to start the process. Failed to initialize CoreCLR, HRESULT: 0x80131500

I just installed ASP.NET Core RC2 and was able to get it working from the command line, on some new basic tests projects. But when I tried to do it from Visual Studio I got the following error. 

If I tried to run "dotnet" in a console opened from Visual Studio, I would get the same error. So the issue was that something was off for the VS configuration/environment. 

After verifying that "dotnet" was able to run perfectly everywhere else I took into the task of comparing the environment variables (dichotomically, of course). One particular variable made the difference: "JUSTMOCK_INSTANCE=XXXXX", so that lead me to notice that JustMock was interfering with it somehow. 

So, if you use JustMock just turn it off for RC2 projects. (No need to uninstall it, just disable the profiler)