Hi All,

Lately I've become quite concerned with my ability to design good architectures at work (not games) and in my own projects at home.

Does any one have any suggestions for books to read, or techniques to follow?

Any tips on focusing would be great.

My main issue is that in an effort to make progress and get results, my classes grow too large and have too many responsibilities. If I try to clean them up, or focus on keeping a clean design, I over complicate the design with generic purposeless classes that are unusable, inflexible and hard to follow. And that is only if I'm not staring at the screen worrying about it.

I work in a small team and am the only senior developer, I don't feel there is anyone I can learn from and I want to help my team and not lead them down the wrong path.

Again, any advice or tips would be greatly appreciated, apologies if this is in the wrong forum, its kind of technical and career related, if it belongs elsewhere let me know.

Thanks,

Arthor.

Hi ArThor,

my opinion might not be the most valuable because there are much more experienced and skilled people on this forum but I was in a very similar situation trying to find a solution. So here are my 2 cents:

As I was starting to find a solution to this problem a pretty long time ago (1 year+), I was constantly browsing the web trying to gather as much information on this topic as I could. Relatively early in this process I noticed that most of the information were based more on experience than on some recipe that could be applied. This is also the reason why I would say the solution is not always in the books, regarding this topic.

Later on I stumbled upon a slideshare of Joshua Bloch stating the following: "Write to your API early and often."
This is what helped me a lot.

But this statement can be expanded even more - to something like: "Let others write to your API early and often."
In this way you can easily locate issues with your code design because others might not think the way you do and the code was designed for. Furthermore you can get input from someone that might use your code in the near future and you will know how he expects to interact with it.
As soon as the API design is on a pretty decent level you can start implementing your code. And because the API acts as kind of a boundary, your code (the actual implementation with all its details) is forced in the right direction. Yeah, it's still possible to create a monolithic class handling all different things but it will feel wrong because you will need to work against the API.

The slideshare mentioned above can be found here: Google API Slideshare

Thanks for the book recomendations guys, I'll have a look into getting a few of them. Thanks for the advice Lumia, most of our work is used internally only but I might try getting my team mates to give more feedback...

If anyone has more advice I would appreciate it.