How do I know if I am overanalysing?
I've been chasing a problem the last 3 days. I've been through many designs and reached a complex solution using about 3 classes. Having discussed with a colleague, I realized that all I need is one method and a struct. How can I avoid being an architecture astronaut?
I used to suffer from this problem. Designing a solution which could handle a lot of growth in the future and what not. Ensured it had good abstraction resulting in the type of concern you had above.
I then dumped this approach and whacked it all into one big dirty class maybe two. After that I re factored it until it resembled something I'd want someone else to work on.
I find that if I can't come up with a good clean solution in 30 minutes, it's almost always best to discuss it with someone else.
Even if they have no idea how to resolve it, it often triggers a better design or solution.
So talk to someone about it.
Personally, I can't really complain about anyone who actually PLANS their software first! I do this, but I know LOTS of programmers who only know how to just jump right into the code... and I often have to fix such code...
That said, what your really asking is how to know when there is a better solution to the problem.
The advice I have for you is to ask yourself repeatedly: Am I thinking about the details of my solution, or about the real problem?
I like doing something quick & dirty first, and when it works, I refactor the code step by step until I'm satisfied with the design.
This is also the TDD approach.
I find myself following these three steps to find an 'ideal' solution:
If I had all the time and resources in the world, what would be the best solution in any way. (Technologically, Logically, Performance-wise, optionally solving a few related issues, re-writing modules you find could do better...) Do your (over-)analysis here, just to get to know about as mush as possible. Run tests, statistics and create proof-of-concept's.
How is it different from the current situation. What is the difference between the results of the two solutions. Is there a faster way to get to the same or similar result. Why would this or that change solve the problem at hand. Do some more tests, statistics, update your proofs-of-concept.
Find a way to implement the required changes, and only the required changes, drop anything not essential to this change. Check you're not modifying anything that was not having the problem. Test this, review changes to code, logic, structure; and minimize them if at all possible.
This sounds very restrictive (and a lot of work), but in fact I find myself I end up adding an entire table to the database in some cases. Part of the work (because it's a lot of work to get 100% sure of something) is checking all existing code keeps working exactly the same with this extra table to join in.
To top that, in most cases here at work we need to cater for 'transitional data' that remains in the system from before the update, that will have to get produced and shipped all the same after the update.
The best way to avoid become an architecture astronaut is to get into the habit of jumping right in. The best way to jump right in is to write a few tests that will pass when your implementation is complete and correct. That forces to you confront what "done" means from the outset, and it provides a sanity check on the code that will follow.
Then head for a solution.
You might now get there the first time, but the exercise of starting with an idea of what "done" means firmly in mind will help you to ask better questions as you go, and having some acceptance tests done ahead of time will help cull the design space down to something reasonable.