(Part 2) Top products from r/softwaredevelopment

Let me start by saying good code is code that solves the business problem at hand. For someone that really cares about internal quality of software that was a hard thing to accept.

You didn't quite define what you mean by "good" in your question, so I assume you mean adherence to SOLID principles. I've long thought like this too but realized adherence to some metric by itself is not very helpful, exactly because you end up in situations where your code is overdesigned, or worse, has the wrong abstractions.

What helped me figure out where the line is was stepping away from SOLID and focusing on Test Driven Development (TDD). TDD is great because it forces you only to write as much code as you need, not more not less. But in order to write testable code you'll have to apply SOLID principles. So you end up with code that reaches just the abstraction level you need to solve the business issue you're trying to solve.

The interesting aspect of this is that there's no clear universal line you can draw and say "this is too much design!" or "this is too little!". What I've observed is that there's just the right amount of design, and interestingly that's, at least in my opinion, a function of how much change you expect. Writing a 100 line hack to do something that you'll never change again is perfectly good code - it does what you need it to, it has certainly no wrong abstractions or over design. But as with most software, change is inevitable and with change internal quality becomes more important. If your code has good internal quality changing it is easier. The better the internal quality, the easier, within limits. So finding the line is an interesting exercise to balance the cost of design vs the expected rate of change.

If I may recommend some reading here:

• Sandi Metz' blog post on the cost of wrong abstractions and I highly recommend her other blog posts
  
• Growing Object-Oriented Software, Guided by Tests helped me figure out how to think about software quality and how to better design it

Could you post a link to the negative response you received? I would be curious to judge it for myself.

There was a fairly strong anti-OO backlash that I would place in the early 00's up to about 2008. The furor has since died down (or at least I'm no longer seeing anti-OO blog posts like I used to). If you're interested I could probably dig up some more, but off the top of my head:

• Execution In The Kingdom of Nouns
  
  
• Why Arc Isn't Especially Object Oriented - and in particular "the smartest programmers [Graham knows] are some of the least excited about [Object Oriented Programming]".
  
  
  Personally, I'm not a huge fan of OOP. It models some problems very well, such as GUI widgets and simulations. But in most domains it tends to result in a bunch of scaffolding that becomes a permanent part of your code base. It is a crutch for when you poorly understand your problem - objects give you something "concrete" to grasp and this is fine for a first pass - but ultimately you should prefer cleaner and simpler abstractions that more closely map to the problem domain.
  
  I also think that C++ is a horrible language for OOP. It's not flexible enough and thus requires a great deal of biolerplate to achieve object-like behavior. For OO-tasks I prefer to work in Smalltalk-inspired languages like Python or Ruby. In particular, characteristics of "real" OO languages would be: late-bound, dynamically typed, and introspective.
  
  Instead, when I work in C++ I prefer to use (what I think of as) "modern style" which was first defined (to the best of my knowledge) in Alexandrescu's book, and is perhaps best embodied by the Boost C++ library style. I realize that this is not everyone's cup of tea. But I think that this is the one area that C++ legitimately shines. It is what I call the "no compromise" style of programming - with the help of template meta-programming libraries you can write your code at a very high level of abstraction, and yet compile it down to extremely efficient code as if it were hand-coded in C to do that specific task. It can be pretty amazing, although it can also be (and probably is) a Turing Tarpit.
  
  EDIT: Not sure why it really matters but: mid-30's, and I work on automotive infotainment systems. C & C++ are the only languages officially supported on the platform, so despite my dislike of C++, I write a lot of it and it is probably my strongest language.

Gotcha. That really sucks, and I mean that in the most meaningful way possible haha.

That type of thinking is the complete opposite of "agile" development, where typically there is a budget, but product owners and devs work together, iteration-by-iteration to determine what needs to change. If an "estimate" is carved in stone, then it's not an estimate anymore, but a fixed-bid project--again, the complete opposite of what developing with agility is supposed to be.

Sounds like a good starting place is learning about lean development and building a minimum viable product, since they're so sensitive about estimate granularity. That manager will have to learn to lead building a very minimum viable product, with as minimally necessary a valuable feature set as possible.

I recommend reading:

• The Lean Startup by Eric Ries
  
• The Lean Product Playbook
  
• Inspired

I'm just now implementing Scrum formally within our company. For me, at the time, it's all upside. I have a CEO & COO that are non-technical (at least as far as software development is concerned), that have really been struggling to understand the team's productivity in a meaningful way.

For me, being able to plan sprints and develop a velocity has been a game-changer. It's very easy now for them to prioritize work and know with a high degree of confidence where we will be after our sprint is finished. That's very important to them, so Scrum really simplifies my life because it's much easier to plan with them using the tools it provides.

I personally purchased Jeff Sutherland's book "Scrum", who was a co-creator, through Audible. Worked pretty well as an e-book, since the complexity is pretty low and most of it was conceptual. https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X/

Try to make a sketch: What are the dependencies of each function / class / module. How are they interconnected, what is the scope of each dependency (can they be bundled into a module / class on its own?). I usually make such sketches on paper -- old school.

If you have the sketch, you can start unbundling it by trying to minimize the dependencies of each part to one another. Once that is done, you can either refactor or outright reimplement the code. Depending on how big the mess is, a complete reimplementation can be simpler sometimes (albeit more time consuming).

There are also very good books on that issue:

• Refactoring by Martin Fowler et al.: This book can be used as a reference for some refactoring methods. It is quite oldish but still very much on point (https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/)
  
• Clean Code by Robert C Martin: This book describes how not to get into this mess in the first place. (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1)
  
• Working effectively with legacy code by Michael Feathers: This book is good when you have to deal with messy code (like in your case). Very resourceful (https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)

Code Complete: http://www.cc2e.com/Default.aspx
Data Stuctures and Algorithms: http://www.amazon.com/Data-Structures-Algorithms-Alfred-Aho/dp/0201000237

• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
  
  
• Design Patterns: Elements of Reusable Object-Oriented Software (aka The Gang of Four)
  
  
• Code Complete: A Practical Handbook of Software Construction, 2nd Edition

The Core Java Series

Python Crash Course

Python Programming: An Introduction to Computer Science