My first contact with computers was with a Spectrum ZX when I was a little child. I’ve always felt a special calling towards the world of technology but I believe that little machine, playing funny video games from an analog cassette tape was the trigger of my passion for this amazing and intriguing universe.
Some years later I got an Intel 80486DX2 PC, as one of my brothers needed it to follow his studies of Statistics at college. Those were the times of MS-DOS, its command-line interpreter and the dawn of Windows 3.1, a new graphical operating system interface that lowered the barrier and opened this world to a whole new spectrum of people.
It wasn’t until the early 2000’s when I got deeper into the study of hardware and software systems and started to learn about them at a deeper level at the University of Alicante (Spain) and Universitetet i Bergen (Norway). From a software perspective, in the early days, this implied the usage of a wide variety of languages such as C/C++, Java, C#, ASP, PHP, Prolog or even assembly code. Lately, I leaned more towards C# and .NET.
Professionally, I’ve always been invested in how to bring new useful ideas and innovations into the world, from inception to production. That’s why I’ve always been connected to the world of startups. First, as CTO at Facephi, building a facial biometrics technology from scratch. Later as a co-founder at Deebbler and Wakeando.
My philosophy, vision, and principles.
My main interest in this area is to understand how to design and bring truly innovative and useful software solutions out into the world.
This is something that has always intrigued me. How can we improve the likelihood of fulfilling that purpose with the solutions we develop?
Well, this question is what made me jump into the study of other fields out of the scope of technology. I needed to gain a more holistic perspective and that led me into areas such as design research, innovation, experience & product design, influence, business design & management…
From a technical standpoint, I’m mostly guided by the Agile philosophy and principles.
If you want to know more about my vision around software systems, you can have a look at this article I wrote some time ago: An elevated vision around software systems.
My approach to software design.
In short, I tend to lean towards evolutionary design as a general philosophy around design, and Domain-Driven Design (DDD) as a more practical and specific framework for building software.
For the long version of this, you can have a look at the following article: Learning and evolution as the key drivers of software design.
My approach and preferred tech stack for software development.
I love learning new tools and technologies. However, I try to keep this bound to my “learning time” and those projects in which, learning a specific technology, adds up to the final outcome and is relevant for the problem I’m solving.
I’m a firm defender of choosing the best technology or solution for the problem at hand. But this also implies finding the right balance between learning new tech and staying with the technologies I already know if they solve the problem well enough (instead of starting to learn new ones just because they are cool).
I know that, as technical people, often this is something hard to do for us. However, I try to keep the focus of my excitement on the problem and not on learning a new trendy technology if it doesn’t help us make progress.
I’ve worked on different types of projects, technologies, and platforms throughout my career, both academically and professionally. From low-level assembly programs to web and desktop applications going through compilers. From Windows to Linux, through MacOS. From domotics to education, going through AI, e-commerce or social networks.
In the last years, however, I’ve been more focused on distributed web applications.
I’m kind of a polyglot engineer.
This is just a simplistic generalization but, on the back-end, the most common stack I use is based on C#, .NET, Entity Framework, SQL Server/MySQL, Windows, and Azure.
I’ve also worked with C/C++, Java and PHP based stacks in different scenarios in the past.
On a more subtle/basic level, I also built some simpler programs on languages & frameworks such as Grails, Node.js, Objective-C, Visual Basic, Perl, old ASP, and others.
My view around testing.
In my opinion, we should build software that is automatically testable. This gives us confidence and safety to evolve it in an agile way. Otherwise, we might get into a complex mess that is hard to alter. And, among other things, this commonly leads to fear of change.
This occurs when we don’t know which undesired side effects we could cause by altering even the smallest piece of software. And that is, actually, what automated tests can help us with: provide us with a safety net that gives us more or less certainty about new changes not breaking the codebase. Obviously, the level of confidence we get will depend on the coverage those tests offer.
There are various practices around the Agile world, aimed at building automated tests for the code we build. Approaches like test-driven development (TDD) or behavior-driven development (BDD) are more or less accepted common-practice inside the software industry, especially among Agile teams.
However, in my opinion, they are too prescriptive regarding how tests (and functional code) should be built. In practice, I’ve found that these are all approaches that work well for me in some scenarios but not so well on others. That’s why I prefer to attain the base principle of self-testing code as outlined by Martin Fowler and decide the specific approach to use depending on the scenario at hand.
In general, I tend to place more emphasis on system-wide integration tests than on unit tests.
For me, it’s a matter of finding the balance between productivity and safety/confidence. Obviously, this greatly depends on the system being developed and how critical potential failures can be. Also on the maturity of our understanding of the domain and the state of the design.
For example, when we are starting a project, the result we look for might still be too vague and subject to rapid and big changes (we are in exploratory mode) and beginning with TDD might not be the best use of our time yet.
Again, this is just a very arguable opinion. Actually, there is an interesting ongoing debate around this topic. If you’d like to expand on it and know where the conversation is headed, you can have a look at this discussion Martin Fowler, Kent Beck, and DHH held some time ago in this respect.
From my point of view, design, testing, and development should be integrated with deployment, operations, and maintenance as it reinforces a collaborative team culture towards a shared end of building useful software for users. A culture of shared responsibility.
This contrasts with the traditional perspective of working in silos which, not just in my opinion, led to an unhealthy culture of blaming which in the end did not benefit anybody (including users particularly).
Actually, this philosophy is what the DevOps movement is all about.
I also advocate for the usage of related Agile practices in this respect. This includes things such as Continuous Integration, Continuous Delivery or Logging, and Monitoring.
In the past, I’ve helped teams I’ve worked with to feed on that culture. Also to automate their deployment pipelines. I’ve mostly done it through the following tools and technologies:
- Version Control: Subversion, Git
- Continuous integration & delivery: Jenkins, GoCD, Visual Studio Online
- Build and deployment automation: MSBuild, Grunt, Gulp, Powershell
- And others I might be forgetting at this moment (sorry for that 😅).