People often think that projects get slower as code is added. However, the systems we work with are dramatically more complex and based on more pre-existing code than ever before. Because that pre-existing code has been generalised out, we can write new code easily and quickly.
There are two situations that you need to think about wrt to this issue (IMHO). If someone needs to do something that you have already done in your project, it should be simple and obvious how to do it. The more often something needs to be done, the more simple and obvious it needs to be. However, if someone needs to do something that hasn't been done before (even if it is is very much related to what already exists), then all doors should be open. The code should not imply how new work should be done. It definitely shouldn't try to guess what you want to do and do it before you get there.
<sarcasm> This could be written on the tombstone of JS. </sarcasm>
But yeah
BufferedReader, FileReader, blah blah blah
http://www.mkyong.com/java/how-to-read-file-from-java-buffer...
Maybe there's a good reason to make it this difficult, if so I'm not aware of it.
var txt = File.ReadAllText("file.txt");
I'm sure there is something similar in Java these days too. Would be a huge mistake to not have simple IO helpers to the std library.
e: fixed typo
If you ever think "we are on schedule and this codebase has just the right balance between getting things done and doing it right" then you have a well composed team.
The article kind of already says this:
> Keep your code absolutely simple.
> Keep looking at your functions and figure out
> how you simplify further.Then maybe that programmer should go into teaching instead?
if teaching earned me as much as a commercial programming job, then yes. Unfortunately, most teaching positions are fairly poorly paid (compared with the qualifications required and the opportunity cost). That's a sad fact, but one has to consider it.
You do realize that this includes all the hackers with the original sense of the term, which are not about finely tuned abstractions and design patterns, but about creating things and hacking/kludging it out to get there faster?
Too many projects suffer immensely because of people who don't give a shit about delivering. In that mode, anything is an excuse: we need to reactor, we need to build a better framework, we need to revisit the requirements, etc.
Then real progress gets slowed down because of some ill fitting development philosophy that some of those folks pulled out of their asses.
What you need are wise programmers that care about delivering product, wise enough to balance long term maintenability and code health with actual delivery schedule.
The keyword is "wise".
But if the job didn't have those elements I wouldn't be in it - and our product would be suffering from that too.
Wise devs are hard to come by.
You once wrote something specific, and it was great. Then you had to write a second thing, and you remember things from the first, so why not make it more general for the inevitable 3rd, 4th, 5th to come? And, then, you fail to deliver the 2nd.
It's easy to confuse abstraction (choosing to deal with one, possibly newly contrived, concept over another) and generalization (reducing the number of concepts required to explain something to a minimum). The former is like building a Haswell CPU from a description of 70s microcontroller architecture, whereas the latter is like trying to figure out what CPUs were like in the 70s by looking at a Haswell core under a microscope.
The quote refers to a future product, one that is very likely unspecified at best, and more likely just something that an individual contributor dreamed up. Unless we have some sort of multi-phase contract, how do we know we'll ever build another thing like this again?
Markets change, hardware changes, experience changes. Hell, building this thing may show you that you should never build another one like it.
Generalize where sensible inside the project, sure. But as the quote says, build what you're building, not what you're not.
All abstractions have a cost and no abstraction is better than the wrong abstraction.
I found this talk on the topic very interesting https://youtu.be/4anAwXYqLG8
prefer duplication over the wrong abstraction ( https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... )
Increasingly I try to find a strategy that transitions towards the generalization over time by following a path of "lower friction instead of greater friction." It's easy to increase friction by adding a new configuration step, new concepts and idioms that are discordant with the rest of the environment, and then the point of doing it gets lost - you don't want to pay for that overhead most of the time, you can't ship code that way.
Didn't someone say premature generalization is the root of all evil?
Sometimes the static array of factories contains a single factory. Creating a single item. No variation, no types, just one kind of one item.
The item is needed once. In one place.
A bit like the Wright brothers building a wind tunnel, so they could experiment quickly with control systems.
But Id wrote some great games, so maybe I'm missing how they handled this aspect...
This really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.