7 (+1) Secrets: #0 - Maintainable Code goes beyond Technology. #1 - All code is equal (...but some code is more equal than others.) #2 - Complexity isn't the problem (...at least not on its own.) #3 - Your brain is not your friend. #4 - Know your change patterns. #5 - (Most) Organizational Problems are mistaken for technical issues. #6 - Find your blind spots. #7 - Make it fun.
What if code isn't changed because it has technical debt? If isn't changed because it has technical debt, if would invalidate the hypothesis Adam said, "you should focus on removing technical debt from code that is changed a lot". Almost by definition, if code is being changed a lot is it easy to work with, and has low cognitive load on the developer. That could be because developers are familiar with that code, rather than the code itself is simple.
You make a good point, but I don't think it's necessarily always the case that frequently-changed code is easier to work with. It may be the case that it's frequently being changed because a lot of bugs are getting reported there, or that the important features are there so the product managers keep pushing for changes, or even because it's a ball of code that contains a lot of important responsibilities within the program. Especially in these cases, the code may be quite complicated, but developer familiarity means that they're not going to change the structure to improve things - they'll just tip-toe in, change what looks like it needs changing to add the new feature, and then tell the product manager that they were warned that it might break. Or you'll get a new developer come on board and then have to spend a week just getting to understand how this service works before they can actually contribute any changes.
I tried to write a "tries" datastructure one. No it is not, the lack of syntax makes it unreadable. But as a toplevel assembly of components - the task that are never algorithmic complex - it might be useable.
I agree. I must admit that I haven't watched the whole talk, but when he starts measuring the value of code refactoring based on diff frequency on the source code, my interest wanes. I think it's a pointless metric and it's even more pointless to apply it to individual files. If anything, it should be applied on the project as a whole and used to compare multiple projects to establish which one may benefit the most, because it's most active. The majority of time in programming is spent reading, understanding and reflecting on existing code. Refactoring, both at class level and at an architectural level, is about reducing the time you must spend to reason about the system to decide on a proper implementation of something new and reducing the risk of you getting that implementation wrong.
7 (+1) Secrets:
#0 - Maintainable Code goes beyond Technology.
#1 - All code is equal (...but some code is more equal than others.)
#2 - Complexity isn't the problem (...at least not on its own.)
#3 - Your brain is not your friend.
#4 - Know your change patterns.
#5 - (Most) Organizational Problems are mistaken for technical issues.
#6 - Find your blind spots.
#7 - Make it fun.
Did a really good job in keeping secret those 7 secrets
Very interesting take.
Fantastic talk, incredibly practical.
To clarify implied: to support your decisions with data - test against your assumed hypotheses
"Fun is virtually a guarantee that things get done."--nice!
What if code isn't changed because it has technical debt? If isn't changed because it has technical debt, if would invalidate the hypothesis Adam said, "you should focus on removing technical debt from code that is changed a lot".
Almost by definition, if code is being changed a lot is it easy to work with, and has low cognitive load on the developer. That could be because developers are familiar with that code, rather than the code itself is simple.
You make a good point, but I don't think it's necessarily always the case that frequently-changed code is easier to work with. It may be the case that it's frequently being changed because a lot of bugs are getting reported there, or that the important features are there so the product managers keep pushing for changes, or even because it's a ball of code that contains a lot of important responsibilities within the program. Especially in these cases, the code may be quite complicated, but developer familiarity means that they're not going to change the structure to improve things - they'll just tip-toe in, change what looks like it needs changing to add the new feature, and then tell the product manager that they were warned that it might break. Or you'll get a new developer come on board and then have to spend a week just getting to understand how this service works before they can actually contribute any changes.
Are there any automated tools that can help me do this myself?
Yes, have a look at CodeScene which is free for open source: codescene.io/
Could you please explain what is teh reasoning behind the use of Fractal Figures diagram? Wouldn't a regular pie-chart do alright?
9:46 it only took 56 victims before the police got a clue lol
I like how he compared software engineers and sex offenders
Gorilla videos:
th-cam.com/video/vJG698U2Mvo/w-d-xo.html
th-cam.com/video/IGQmdoK_ZfY/w-d-xo.html
Common LISP is a great language.
(s
(u
(r
(e
!)))))
I tried to write a "tries" datastructure one. No it is not, the lack of syntax makes it unreadable. But as a toplevel assembly of components - the task that are never algorithmic complex - it might be useable.
Tragedy of the commons type situation on the code parts that have had many different people change it.
Can someone explain what the point of this talk is?
+1
from what I gather: applications of data analysis, forensics, psychology to software engineering.
No offense, it's extremely difficult to understand his point.
how to find hotspots and make your code more maintainable
I agree. I must admit that I haven't watched the whole talk, but when he starts measuring the value of code refactoring based on diff frequency on the source code, my interest wanes. I think it's a pointless metric and it's even more pointless to apply it to individual files. If anything, it should be applied on the project as a whole and used to compare multiple projects to establish which one may benefit the most, because it's most active.
The majority of time in programming is spent reading, understanding and reflecting on existing code. Refactoring, both at class level and at an architectural level, is about reducing the time you must spend to reason about the system to decide on a proper implementation of something new and reducing the risk of you getting that implementation wrong.
nice talk
Wasn't this old "GOTO" introduction SO much less annoying than the "boom bang zoom" of the newer intro.
not arshitecture, but arkitecture
3:02 Conway's Law give him credit!