Agile and the long crisis of software
I&#x27;ve been developing software for 40 years and here&#x27;s my unsolicited observations:<p>- Projects always take longer than anyone expects, even when accounting for projects taking longer than anyone expects (Hofstadter&#x27;s Law)<p>- The project architecture will reflect the organizational structure of the entity creating the software (Conway&#x27;s Law)<p>- The above two points are often presented as jokes but they are not, they&#x27;re both actually true<p>- You cannot force two people who do not like one another to pair program<p>- 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<p>- Code reviews are a waste of time and present a great opportunity to destroy team morale<p>- Software development attracts a lot of assholes and prima donnas who all believe they are the fabled 10x developer<p>- It is just as important to understand the <i>why</i> of a feature as it is to understand the <i>what</i> - developers need to understand <i>why</i> a feature is relevant and what problem it&#x27;s solving for users to be able to best implement it<p>- Invest in automated unit testing, application build, packaging, configuration and deployment. This is your best defense against Hofstadter&#x27;s Law.<p>- 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.<p>- Some teams have a knack for success regardless of the software development methodology being utilized. They can also use the &quot;bad&quot; application frameworks and development languages and still be successful.<p>- Mutual respect and everyone pulling their weight are the best predictors of a team&#x27;s success<p>- Just because someone isn&#x27;t working out well on one team doesn&#x27;t mean they won&#x27;t excel on another team. Some people will excel regardless of the team they&#x27;re placed on. There are also a few, very few, who can&#x27;t seem to excel anywhere.<p>- Some people aren&#x27;t cut out for development and since 1960 we&#x27;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&#x27;s tragic to watch people sink - especially when you can&#x27;t put into words why they&#x27;re sinking and how to start swimming.<p>- Outsiders believe developers are anti-social and don&#x27;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&#x27;ll probably have lots of problems with the members of your development team. Of course this isn&#x27;t 100% accurate, but it&#x27;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.<p>- Finally, management is key. If you fundamentally disagree with your management then it&#x27;s time to move on. There&#x27;s no need to trash the management when you leave, all you need to say is you don&#x27;t feel you&#x27;re aligned with their goals and priorities. Some people may like the management, others may not. Don&#x27;t take it personally.