3 ms·

I've been developing software for 40 years and here's my unsolicited observations: - Projects always take longer than anyone expects, even when accounting for

I've been developing software for 40 years and here's my unsolicited observations: - Projects always take longer than anyone expects, even when accounting for projects taking longer than anyone expects (Hofstadter's Law) - The project architecture will reflect the organizational structure of the entity creating the software (Conway's Law) - The above two points are often presented as jokes but they are not, they're both actually true - You cannot force two people who do not like one another to pair program - Pair programming should never be forced on developers, let developers decide when to pair and whom to pair with - this is the autonomy developers seek - Code reviews are a waste of time and present a great opportunity to destroy team morale - Software development attracts a lot of assholes and prima donnas who all believe they are the fabled 10x developer - It is just as important to understand the why of a feature as it is to understand the what - developers need to understand why a feature is relevant and what problem it's solving for users to be able to best implement it - Invest in automated unit testing, application build, packaging, configuration and deployment. This is your best defense against Hofstadter's Law. - Some teams have a knack for failure regardless of the software development methodology being utilized. The same is true for application frameworks and development languages. - Some teams have a knack for success regardless of the software development methodology being utilized. They can also use the "bad" application frameworks and development languages and still be successful. - Mutual respect and everyone pulling their weight are the best predictors of a team's success - Just because someone isn't working out well on one team doesn't mean they won't excel on another team. Some people will excel regardless of the team they're placed on. There are also a few, very few, who can't seem to excel anywhere. - Some people aren't cut out for development and since 1960 we've been trying to figure out who those people are and dissuade them from entering the profession - all to no avail. This is a sink or swim profession and it's tragic to watch people sink - especially when you can't put into words why they're sinking and how to start swimming. - Outsiders believe developers are anti-social and don't realize modern development is a team sport. The best predictor of success is how well you were able to play team sports. If you always had lots of problems with your team mates then you'll probably have lots of problems with the members of your development team. Of course this isn't 100% accurate, but it's a good predictor. Those playing well in team sports, play in bands, or have been involved in dramatic productions tend to work well. Basically any activity having a group of people work together towards a common goal. Loners do not work well on development teams - they find success on skunk work projects. - Finally, management is key. If you fundamentally disagree with your management then it's time to move on. There's no need to trash the management when you leave, all you need to say is you don't feel you're aligned with their goals and priorities. Some people may like the management, others may not. Don't take it personally.

digisign 5y ago
Generally agree, but disagree with this one: - Code reviews are a waste of time and present a great opportunity to destroy team morale CR has prevented an uncountable number of issues in our large codebase with junior devs. It doesn't have to reduce morale if used as a teaching moment (growth mindset) instead of opportunity for punishment. Imagine a sports team without a coach. "Just have experts (only) work for you," isn't a solution for most either.
p0nce 5y ago
> Code reviews are a waste of time and present a great opportunity to destroy team morale Great post, but we would have to come to agree on that one somehow, because in Capers Jones books, code reviews are measured to be the #1 most effective method at improving quality. I'd agree they are very easy to do badly, and often overused.
throwaway6532 5y ago
This is an amazing list, though I'm curious given how accurate the rest of this list is how you drew the conclusion that code reviews are a waste of time?
- taylodl 5y ago
  Three people commented on my calling code reviews a waste of time. To kick off my discussion, I should reveal that I stopped doing code reviews 20 years ago. That actually turns out to be significant. Here's why. For the first 20 years of my career I worked at 5 different places and so have some experience with different development cultures. They all did code reviews and they all had the same flaw - they focused almost exclusively on all the wrong things. There would be endless arguments about indentation, braces placement, variable naming and so on. A little bit of the time was spent on what actually matters - the implementation. C++ (which was hugely popular in the 90's) made this even worse - now people could argue about whether a function should be overridable (virtual), whether members should be private, and on and on and on and on. After a few years of working on our own internal framework and working with commercial frameworks it dawned on me that nobody got it right. Meanwhile all these inane arguments led to time being wasted, projects missing their dates, team members arguing over stupid crap - ugh! I saw this with multiple teams across multiple organizations. Different people, same problem. So what happened 20 years ago? That's when what we now call CI/CD tools first started appearing (remember Cruise Control?). With that we saw the advent of automated unit test frameworks, tools that could check the code against coding guidelines, and tools that could measure the amount of CRAP (Change Risk Analysis and Predictions, remember Crap4j?) and assess the security risk the code imposes. All of this is automated. I saw that automating the code reviews could get rid of a lot of the negativity, be objective, and focus on the implementation and quality of the code. This is the way. When code is pushed to the repo I have evidence of it's quality: I know it conforms to our coding conventions (which I'm not a big believer in, but some people like to die on that hill), it's been tested (we require 40% test coverage and getter/setter tests don't count), it's CRAP score has been assessed, and it's had a security scan looking for vulnerabilities. All automated. When working with junior developers they get immediate feedback on the quality of their code and can fix it. If they don't understand how to fix it then they reach out to one of us and we can help mentor them as to what is being reported and what the actual issue is. It's all very positive. What I should have said then was manual code reviews are a waste of time - you want to automate that activity! I don't ever want to see a code review activity scheduled on my calendar!

digisign 5y ago

Generally agree, but disagree with this one: - Code reviews are a waste of time and present a great opportunity to destroy team morale CR has prevented an uncountable number of issues in our large codebase with junior devs. It doesn't have to reduce morale if used as a teaching moment (growth mindset) instead of opportunity for punishment. Imagine a sports team without a coach. "Just have experts (only) work for you," isn't a solution for most either.

p0nce 5y ago

> Code reviews are a waste of time and present a great opportunity to destroy team morale Great post, but we would have to come to agree on that one somehow, because in Capers Jones books, code reviews are measured to be the #1 most effective method at improving quality. I'd agree they are very easy to do badly, and often overused.

throwaway6532 5y ago

This is an amazing list, though I'm curious given how accurate the rest of this list is how you drew the conclusion that code reviews are a waste of time?

taylodl 5y ago
Three people commented on my calling code reviews a waste of time. To kick off my discussion, I should reveal that I stopped doing code reviews 20 years ago. That actually turns out to be significant. Here's why. For the first 20 years of my career I worked at 5 different places and so have some experience with different development cultures. They all did code reviews and they all had the same flaw - they focused almost exclusively on all the wrong things. There would be endless arguments about indentation, braces placement, variable naming and so on. A little bit of the time was spent on what actually matters - the implementation. C++ (which was hugely popular in the 90's) made this even worse - now people could argue about whether a function should be overridable (virtual), whether members should be private, and on and on and on and on. After a few years of working on our own internal framework and working with commercial frameworks it dawned on me that nobody got it right. Meanwhile all these inane arguments led to time being wasted, projects missing their dates, team members arguing over stupid crap - ugh! I saw this with multiple teams across multiple organizations. Different people, same problem. So what happened 20 years ago? That's when what we now call CI/CD tools first started appearing (remember Cruise Control?). With that we saw the advent of automated unit test frameworks, tools that could check the code against coding guidelines, and tools that could measure the amount of CRAP (Change Risk Analysis and Predictions, remember Crap4j?) and assess the security risk the code imposes. All of this is automated. I saw that automating the code reviews could get rid of a lot of the negativity, be objective, and focus on the implementation and quality of the code. This is the way. When code is pushed to the repo I have evidence of it's quality: I know it conforms to our coding conventions (which I'm not a big believer in, but some people like to die on that hill), it's been tested (we require 40% test coverage and getter/setter tests don't count), it's CRAP score has been assessed, and it's had a security scan looking for vulnerabilities. All automated. When working with junior developers they get immediate feedback on the quality of their code and can fix it. If they don't understand how to fix it then they reach out to one of us and we can help mentor them as to what is being reported and what the actual issue is. It's all very positive. What I should have said then was manual code reviews are a waste of time - you want to automate that activity! I don't ever want to see a code review activity scheduled on my calendar!