On code beauty, and software as a painting

Emad Elsaid
2 min readSep 29, 2016

--

I have been always fond of drawing and painting alongside programming, and I have always sensed that bridge between software engineering and painting a picture, that hidden link that makes you feel that your code is ruined by other people patches and modifications, while their contributions are completely legitimate but you still feel it doesn’t fit in the picture you draw.

When we solve a problem with a piece of software we tend to create a mental model of the problem then we attack that model with a solution that fits in , that fix it or morph it to solve the problem in hand, and you proceed to write the code that represent the solution, that’s how we do it, large or small problem we follow these steps, our solutions could be splitting the problem into a smaller chunks or reducing the problem to a core covered by multiple layers…etc, at the end we have to build a model of how the problem looks like, and as a person thinking differ depending on what he experienced throughout his life, then the produced thinking model also differ from one developer to the other.

and as the model we form in our minds differ the solution must also has to be different, this is why no two developers can write the same exact code.

as the software developer try to solve a problem by building a software for it, it become like a painting, the whole thing fits together, patterns could recur and in general the whole structure is in harmony, another developer can come up with a another solution of course, but it’s like two designers coming up with two designs for the same website, yes you can choose one over the other because it is prettier or any other reason.

The problem we have is that when you like parts of each design and you want the two designers to join these two parts in one product, it won’t be a better design at all, no matter how you imagine it, it’s like asking for frankenstein.

perhaps this is one of the major problems in our industry, developers are trying to force their own mental model to fit in other people models, trying to write a well structured code on it’s own but when you see the whole picture your notice it’s a mess, nothing in harmony, every module looks interesting and tidy as a separate unit, but when you put everything together you notice the inconsistency.

this problem in my opinion leads companies to rewrite part of their product which by chance was the most modified part of their software, or sometimes they decide to rewrite the whole application either in different language or adopting micro-services and language agnosticism among the company members.

maybe if we paid attention to other people work and tried to stay in harmony with their whole structure, our products will live longer and be easier to maintain over time, and will save you and your teammates your valuable time.

--

--

Emad Elsaid

A ruby developer, Fantasy/Sci-fi addict, works for @twitter