The Art of Coding: Disasters and Failures, with Fernando Cejas [Droidkast LIVE 01]

I had the honor to have Fernando Cejas as my first guest for Droidkast.LIVE.

We talked about almost two hours about lots of things, related to his life, how to balance work and life, interview processes, sharing with the community, new technologies…

1. The video

You can watch the full episode here:

https://www.youtube.com/watch?v=VK5q8Eyt9Ag

2. The interview: Main questions

1. Tell us a little about your story: where are you from, how was your childhood and what led you to start in the world of software development?
2. I knew about you when you were at Tuenti, here in Spain. Was it your first job? How did you end up working in Spain?
3. Then you moved to SoundCloud Berlin. Was it difficult to move to a country with a different language?
4. Do you think that non-native have to fight more to get the same recognition? How have you felt on that aspect?
5. You talk a lot about kindness and to help each other as a way to grow yourself. How do you think this has helped you in your life, and how do you apply it to your day-to-day?
6. I know you’re nowadays a big fan of cycling. Have you always been into sports before or that’s a recent hobby? How do you feel this new hobby is impacting your life?
7. When you think about your long-term future, how do you see it? Do you think you’ll devote all your life to software development?
8. If you had to recommend just one thing to our listeners, about anything, IT related or not, what would be?

3. The talk: The Art of Coding: Disasters and Failures

The talk was an interesting journey through many of the coding mistakes we usually commit, and how to prevent them:

Software engineering and technology is about constant evolution, which mainly involves continuous improvement. And in order to achieve it, there is long path ahead of us, which many times is not easy to follow up.

Jump onboard in this journey about common (or not) software engineering disasters, failures and mistakes and how we can get the most out of those lessons in order to learn and write/develop better software.

https://speakerdeck.com/android10/the-art-of-coding-disasters-and-failures

4. Transcription

About Fernando

I have been working with many technologies. I have been associated with Android development pretty much from the start, to be exact I started working on Android 0.9 version. I worked in Soundcloud for a few years in Germany. Apart from Android lately I have been working on quantum computing and other nerdy stuff at IBM. Work at IBM is mostly research-related and attend lots of enterprise conferences. Am a big fan and defender of open source software development.

So many architectures, which one to use?

I want to say that ‘It depends’, it depends on your use case. Having a suitable architecture for your project is very important, and I have seen several approaches to designing and arranging your code. There are different theoretical models like MVI, MVP or Adaptors design and there can be different implementations for the same model. We have been discussing a lot about choosing an architecture at various forums whether be at conferences, live broadcasts like this or in blogs. My simple advice is to pick one architecture and stick to it. Holding to one architecture brings consistency to your code base, and it becomes more maintainable for you and others.

Another point to focus is that there are architectures which are more complex than others. Now if you are starting up with one developer then you might need to start with a simple design as choosing a sophisticated design with few developers will lead to over-engineering, e.g., unidirectional architectures like MVI are much more complicated than MVC then MVC could be a better choice for most teams with few developers. I will reiterate the point that you need to stick to one architecture and maybe iterate over it again and have your implementation. If something is working for you then it’s perfectly fine to stick to it. I remember about Martin Fowler’s Sacrificial Architecture in which he says for some projects you may need to prototype fast, and you know that whatever you will write most of it will be eventually thrown away. So when you need to write code super fast, shitty code design, in this particular case will work as it is completing your need to demo some technology. Let’s read some snippet from Martin Fowler:

So what does it mean to deliberately choose a sacrificial architecture? Essentially it means accepting now that in a few years time you’ll (hopefully) need to throw away what you’re currently building. This can mean accepting limits to the cross-functional needs of what you’re putting together. It can mean thinking now about things that can make it easier to replace when the time comes - software designers rarely think about how to design their creation to support its graceful replacement. It also means recognizing that software that’s thrown away in a relatively short time can still deliver plenty of value. While it can be reasonable to sacrifice an entire system in its early days, as a system grows it’s more effective to sacrifice individual modules - which you can only do if you have good module boundaries.

There are many ways to solve a problem and in the end code base created should be easy to maintain and augment in future.

His thoughts on Flutter and in general cross-platform development frameworks

I have not used Flutter much, but frankly, I think it is a bet. It is another attempt to create cross-platform frameworks like react native. There is a considerable number of projects and companies fighting for supremacy in the cross-platform world. Frankly, I will need to see little more of it as it is pretty new. Another point I want to add is that Flutter might be useful for developers coming from web development like react native did and probably it’s a better way of software development for them. I want to reiterate that it depends on your need like less number of people in your team might change your thought process to use something like Flutter. You can use sacrificial architecture here where you start with something like Flutter and then move on to native solution later on. Or you can use a hybrid approach where something like login screen is similar for both iOS and Android, and that can be implemented in Flutter and rest in native.

The Art of Coding: Disasters and Failures

Your first line of code

A person who never made a mistake never tried anything new

You start your new job and probably made some mistakes, and that is fine as long as you don’t repeat them regularly. We are curious and introvert people who like to try new things; probably we can switch to extrovert behaviour when needed. You are always willing to introduce new technologies for your project. But you need to be ready to accept other ideas and limitations that things you find attractive may not be right for your project and you need to find a balance between introducing new elements and augmenting the old code base.

Screwing things up

It happened to me at Soundcloud, It was my second week at my job, and I accepted the challenge to be a release captain for an application which had 100 million users. Let’s look at the big picture of our product:

BFF stands for Backend for Frontend which we were using at that time. It included mobile and web clients. There were different APIs for web and mobile. At that time we did not have the CI (continuous integration), and there were lots of manual steps involved at that time and while publishing the app to google play store I forgot to switch mobile clients to prod environment which routed the 100 million userbase traffic to two mac minis used for our development. With this, users could no more play songs which was our core functionality. It was a horrible moment for me, and I said to my mom that I am the worst employee and will get fired in first week of my job for this.

May the force of failure be with you

Fact: Our Software is terrible

Our software is terrible. And that does not make it special. All software is terrible and that it is true.

Types of Mistakes

Product Mistakes

1. FitSpoon: You are moving too fast thinking that big data is feeding your product, but soon you realized that lots of things are missing and you try to increase the number of releases to have more content. If you are in this trap then better you get off it as soon as possible.

   

2. Throne Master: If you are comparing and quantifying with a tiny group and better results in that is making you happy, then you are set to be doomed sooner or later.

   

Process Mistakes

This includes process related to software development like releasing, hiring, management etc.

Coding Mistakes

Main bad practices we follow as engineers and hints on how to use good practices.

1. Readable code: Code must be self-explanatory.

   1. Comments do not work as they are always outdated.

   2. Refactor is our friend. Below code is too cluttered and difficult to read:

      public void path(Node myNode, Key k) {
          Node h = myNode.find(k);
          if (k.compareTo(h.key) < 0) {
              if (!isRed(h.left) && !isRed(h.left.left)) {
                  h = moveRedLeft(h);
                  h.left = delete(h.left, k);
              }
          } else {
              if (isRed(h.left)) h = rotateRight(h);
              if (k.compareTo(h.key) == 0 && (h.right == null)) h = null;
              if (!isRed(h.right) && !isRed(h.right.left)) h = moveRedRight(h);
              if (k.compareTo(h.key) == 0) {
                  Node x = min(h.right);
                  h.key = x.key;
                  h.val = x.val;
                  h.right = deleteMin(h.right);
              } else {
                  h.right = delete(h.right, k);
              }
          }
          balance(h);
      }
      

      Below code is more readable as we have renamed and separated different pieces of code:

      public void deletePath(Node fromNode, Key key) {
          Node node = myNode.find(key);
          //some logic
          deleteNode(node);
      }
      
      private void deleteNode(Node node, Key key) {
          if (key.compareTo(node.key) < 0) {
              if (!isRed(node.left) && !isRed(node.left.left)) {
                  node = moveRedLeft(node);
                  node.left = delete(node.left, key);
              }
              ...
              return balance(node);
          }
      }
      

      Refactoring is our friend.

   3. Code must be written in English.

   4. Be kind to the person maintaining your code.

2. Reinventing the wheel Reusing code from other projects is the most efficient thing you can do as developer. If you can use API from some framework or library then please use it. This will help you saving huge amount of time and help you focus on your idea.

3. Naming is complicated In the example below I end up with multiple parsers and one of them was right as others were deprecated. It is not possible to determine which one to use without checking out those individual parsers in the code.

   1. Refactor the names.
   2. Use deprecate annotations.

   

   

4. Anti Patterns Detecting anti-patterns are key to maintainability in the code base. Using anti-patterns like Singleton and Lava will lead to difficulties in maintaining the code base. Singleton should only be used where object creation is very expensive and should not be used for storing global state as it can lead to weird behaviour and debugging that will be very difficult. Similarly, Lava pattern advocates using different ways to do the same thing which again brings heterogeneous behaviour and it is difficult for user of the code to stitch pieces together and have a big picture of your code base. Similarly having God class with thousands of lines of code is extremely difficult to maintain and we should avoid it.

5. Follow Programming principles

   

6. Patterns and code consistency Patterns are common or proven solutions to problems. It creates a common language which leads to better maintainance of your code base. Consistency is defined as: sameness, conformity, uniformity. Unwavering consistency within a system leads to code where you can make more assumptions and predictions about its behavior and implementation that end up being accurate.

7. The boy scout rule. Continuous improvement is key. You don’t have to target big refactors, refactoring small pieces of code will help you in the long run.

8. Code is way to communicate between different people.

Good practices

Zero bugs application

Don’t be sad

Learn from your mistakes

Share your experiences

Share your experiences and platform can be meetups, blogging, videos etc..

Conclusion

We all make mistakes and always remember that there are people like me who have made mistakes in past and they kept learning from their mistakes.

5. Links mentioned during the interview

• Fernando’s blog
• Fernando’s Twitter
• Slides from the talk

6. Subscribe to Droidkast.LIVE

If you don’t want to miss the following episodes, join the mailing list to receive new updates here.

I’ll come back soon with new awesome guests!