Ask HN: I have a mental block designing software. Time to quit?

If the code is tested then refactoring the ideas contained within is the way to go. Do the smallest refactorings possible. Even well-respected programmers who've authored tons of books and given talks do not sit down and 1-shot a program. Elegant programs are the result of refining and designing.

The earlier in the development process you get to the refactoring and isolating minimal testable components, the less of a tangle you have between components to refactor; it's a lot like the wire tangles we're all so familiar with). This not only means less refactoring, but it also means that the existing code is easier to understand.

The tests are code. Treat the tests just like the rest of the code. I prefer test-first but if you want to pull your cart in front of your horse then go for it.

If the code is not tested I'd recommend testing it. There are really only 3 options to go from untested code base to tested code base: - Try to put tests under existing code (often inefficient) - Refactor the system incrementally as time goes on and features are added and bugs are fixed (slow process but over time test coverage grows) - Throw it out and start over (ouch but... greenfield; if you do this you should _NOT_ add any new features to the live/production system or you'll end up in a rat race between the two forever)

Also if you're able to take any time away (preferably measured in days) the fresh perspective might help too. Sometimes that little bit of total separation is enough to come back and read a method name and wonder why the hell it's even in that particular class. This scenario could be an early warning for burnout too, take care of yourself!

> When you know the requirements, model the data first. Data comes first because data lasts longer than code. Flexible data lets you do more with less code. And if the data is very well defined you can usually use fewer language features, too - which is a bonus to maintenance later. Think of features in data terms first and lifecycles later.

Boy am I SO GLAD to see someone say that! I think of my approach as "Data-Driven Development", rooted in my days of scientific programming. The data is what matters. On my largest project to date (8 months, entire business system) I spent 25% of the time just on the data store schema. Needless to say it worked & evolved without issue over 5 years.

Yet (at least in the PHP community) the fad is currently Domain-Driven Development, BDD, and architectures ("another travesty of reflection and classes-on-top-of-classes").

> The maintainers will feel like geniuses because they'll keep finding clever ways to use the existing data better

Oh yes, that's how my oldest systems are. Spaghetti code in parts, but the data keeps on giving.

Thank you for taking the time to write this, you've ignited a small flame of enthusiasm in me and reminded me why I enjoyed doing what I do!

>The PHP community (where my commercial work is done) is not that. And far too fad driven.

If you have the insight to recognize this, I think you are doing fine.

I would recommend Python as it's community seems to be a bit better. It sure is not as 'design pattern' infested. If you have a lot of time to spare and tenacious enough, you can also try Haskell. Although you should not feel disheartened about not understanding 90% of things being said in the irc chat room even after wrestling half year with the language. But I think it is worth giving a shot. I have already ported my side project which was in PHP to Haskell using a framework called Spock and PostgreSQL as backend..

Also, I think the php thing might be causing you this conflict. As I myself have gone through a similar stage. (8 years of professional PHP experience). When I started python 3 and after a while I unlearned certain things from PHP. Things became quite a lot simple.

For example, this is the same static site generator I wrote in PHP and Python3.

PHP - https://bitbucket.org/sras/vodka

Python - https://bitbucket.org/sras/feni

Writing a bit complex stuff using PHP is so damn tiring, but it only became clear that the problem was PHP after I started programming in Python and unlearned enough PHP stuff...

I would add

- Object Oriented Software Construction (2nd. Bertrand Meyer)

I would recommend Eiffel if you want to elevate OO design. The issue with the GOF book that I have is that there is a slant towards composition as opposed to inheritance. When done right inheritance does result in compact code. Multiple inheritance cannot be avoided (Scala proves this by trying to bring in traits). Repeated inheritance actually helps reduce the code size as one could inherit the same method twice to implement a doubly linked list from a single linked list.

Note: In functional paradigm (Haskell) composition over inheritance makes sense, though in object oriented languages choosing an approach that has a compositional bias can impose some constraints that could be avoided otherwise.

It's hard to say without knowing what's already in your current toolbox. But a partial list might be:

* Erlang - Novel approaches to fault tolerant system design. Fail fast and recover somewhere else. Functional without the Type wizardry so you learn about immutability, pattern matching, and the typical functional language tools like folds, maps and so on.

* Clojure - A lisp that runs on the JVM. Learn about Code as data and how that empowers meta-programming. Also a functional language with interesting takes on how to share data in an immutable by default world. Lazy collections of a sort so you can learn about laziness.

* Haskell - Don't let the Category theory stuff scare you. Very interesting type system that can open your eyes to new ways to abstract things. Speaking of abstraction Haskell takes abstraction to a whole other level. Sometimes you can't see the program for all the abstraction going on. Militantly functional.

* Forth - Stack based programming, very small and compact. Radically different than anything else.

* Rust - Maybe you want to go a little bit closer to the metal for a change? Forces you to think about exactly how you share data in a multithreaded world. Targets the same world as C++ but perhaps with an easier to enter community.

* Python - Cleaner more elegant language in the same family as PHP with a very welcoming community. Batteries included so it's easier to get started than any of the others.

* Go - Concurrency done right. Lots of tooling builtin to the distribution toolchain.