Sometimes, I like to think of we developers as surgeons :) .
I guess you heard before "developers are like writers", "developers are like gardeners", "developers are like artists" ... did you know "developers are like surgeons" ?
Here is why I like this metaphor:
Acknowledge the body history
It is quite rare that a developer can build a new system from scratch. It happens, but most of the time he will be asked to add a new feature to an existing system. And this means that his mission is not only to add a new feature but also to make sure all the previously implemented features still work in the updated version of the code.
For complex software (thousand of lines of code), this can turn any easy feature such as "display a red tag when status is 'not valid' " in a coding nightmare. That is why on large codebases even small features can require days of work: adding the new feature is hard, but keeping all others (sometimes hundred of them, for hundred of different usecases !) "still working" is even harder.
Moreover, even if the new feature does not modify the behavior of the other features, for the job to be "done right" the new feature must "fit in" the existing system.
If 99% of the existing features are implemented using a MVC, your feature must be as well. If 99% of the existing features use a no-sql database, your feature must do as well*. This is necessary to keep the system consistent and maintainable. Else you might create a legacy spaghetti code application which means a free ticket for developer hell.
*In most cases. Of course there are exceptions where the cost and maintainance price of having both a sql and a no-sql database are worth the new feature. But it is not often.
This is the 1st reason why I like to think "developers are like surgeons": when a surgeon has to heal you, he must fix your body without breaking your vital (and most of the time also the non-vital) capabilities, and he must do it in a way consistent with the rest of your body. He cannot "cut his way" straight to the injured organ, he might need to zigzag through your other organs to get to its target.
By the way that is one of the big differences between software development courses and software development as a job. Most of computing assignments I have heard about allow the student to create a solution from scratch to the given problem. But in their 1st job these students are going to face an existing system which they need to quickly understand and master in order to be able to add new features. This is one of the hardest challenge of "from student to employee" in our field in my opinion.
Plug yourself somewhere
When one of your arteries is clogged, the surgeon must unclog it. One of the ways to do it is to insert a wire in the artery and travel through your blood circulatory system until he gets to the clog, and put a stent there. The surgeon must then think over where he is going to insert the wire. Sometimes he might insert the wire in your leg although the clog is near your arm because it is easier, provided the circulatory system structure, to reach it from there*.
*I do not know if this is medically relevant, it is obviously just an imaginary example :)
Again in existing systems, developers must do the same. Consider a monitoring dashboard application: there is streams of informations incoming (logs, signals, pings ...) that are redirected in several "pipes" where they are being processed (counted, grouped by category, min and max values always updated ...) and finally the results of the processes is displayed on the dashboard. A well-known example is the Google Analytics "realtime" dashboard. It shows you how many users are "browsing your website in realtime".
I am no google developer but I am going to try to imagine how the "number of people on your website" is computed:
1st: Google server retrieves all pings it receives through its analytics script
2nd: it gathers pings in groups, 1 group per domain
3rd: it looks for duplicates in this group, because if someone has opened 2 tabs on the same website, it is still the same person although 2 pings are sent
4th: it removes duplicates
5th: it counts the number of pings in the group and display them
Now YOU are a google developer. And you are given the assignment "Add to the dashboard the information 'percentage of global traffic' " which means how many people are on your website in comparison to all people on all websites tracked by google.
You can do it in multiple ways:
- before step 1 you can count all pings and obtain a "total number of pings", then after step 2 you compute each group percentage
- after step 2 you can sum all groups counts to obtain a "total" and then compute each group percentage
- after step 5 because then you remove duplicates from your count, which makes it more reliable and you use the "total" computed in steps 1 or 2
So you got to choose "where do I plug myself to perform this task ?". So does the surgeon. Our body is full of streams: blood streams obviously, but also oxygen stream, poop stream ... and when the surgeon must perform something that impacts one of these pipes (dialysis for example), he has to choose where he plugs in on the stream to modify the stream behavior. So does the developer.
Conclusion
I hope you like this metaphor ; I use it sometimes to explain some software development situations.
For example the usual "how many hours do you need to get this feature done ?". Developers are often asked to estimate how long their assignments will require, and we know very well how complex (and consequently inaccurate) this is. I guess for surgeons it is the same.
They can expect a surgical operation to last for 2 hours, however if the patient body is more complex than average it might take longer and the surgeon cannot anticipate it. He will understand this while performing the surgery. This situation is not unfamiliar for developers.
Feel free to tell me in comments other metaphors you like about developers :)
Top comments (0)