What can I do to not worry about always having perfect code and having future scope creep?

Question

I find it an issue nowadays where I spend a lot of time worrying about small details and spending lots of time thinking about whether or not certain things will be an issue in the future. Is there some sort of strategy or technique that I can use to mentally just not worry about it?

Answer 1

Keep things as SIMPLE as possible.

Be a die hard follower of KISS and DRY

After a while you start to develop a 6th sense for when things are just off, and it becomes fun to fix your own bugs before they are bugs.

When you design a system using these principles you rarely spend much time thinking about what could be done better. Each unit of your code is so small and self contained that you never have to worry about it. See also design by contract. When you get past that point your more complicated functions simply build on your unit sized functions and you know they will work and are as nice as possible because you have a good solid foundation you are building on.

Did I mention that this style creates code and applications that benefit TREMENDOUSLY from unit testing? Sometimes I almost forget to do functional testing, because I know every single unit of my code follows their contract and thus will work if the unit tests work, no matter what the situation.

Answer 2

Realize you're Fedor.

Answer 3

Trying to predict the future will drive you insane. No matter how well your code is laid out, there is always going to be some issue/bug that develops in the future. Don't try to make it perfect, just do the best you can and move on

Answer 4

Develop iteratively

Add core functionality first. Then add less critical features.

I often find that making a working product helps to identify what the next steps should be. This can also help you to analyze items that may be an issue in the future.

Another important point to keep in mind is that your requirements will change as the project evolves. By developing iteratively (whether you use a formal process or not) you can adapt to these changes. Worrying about the small details at the beginning of the project may mean that you are worrying about details that will change.

That said, I would agree that planning for the future is an attribute of a good developer. Keeping in mind how your software will evolve and scale is important (or very important depending on your project).

Answer 5

In my opinion, keep doing it your way. With time you'll be doing it faster and with more confidence.

A good developer spends more time thinking than coding.

Answer 6

Many times, the fear of having to add stuff later is rooted in the fact that modifying the code can be painful. A good way to avoid this is to learn strong object-oriented skills and design patterns, and to practice TDD or at least have strong unit tests.

If it's easy to reliably change code, then adding functionality later is less painful, and doing it up front is less important.

Answer 7

Get yourself a project manager. They tend to be very keen on shipping what you got and very against perfection.

Answer 8

It is important you know the technology that you will work with. This way, you can apply good patterns and principles (and code) in order to get the most of it.

Answer 9

Working within a good framework helps with this too.

I've worked on a long, large project where we were not adhering to any framework in particular and as the scope creep inevitably happened the code got really bloated. In the end we just got to the point were to continue development we really had only one option:

Write down all the things we liked about the project, scratch the current system and start again with a decent framework in place...

(there was not very much priority placed on refactoring existing code during this project either... another mistake)

Answer 10

On a project I am working, and successful projects I have worked on in the past, I follow this rough process:

• I spend a lot of time planning and designing, before any code is written.
• I create a document that enumerates all the planned features for the project (that I know of).
• I speak with the users who I am targeting. I interview them, show them the list of features I am planning and maybe a couple of mockups or screenshots. They will, in turn, give me their feedback about these features: whether it's a good idea or not, does it work the way they would expect, is there some crucial missing piece, is it even desirable, etc.
• I integrate their feedback, and very importantly I use my judgment and insight to decide which of their feedback I will listen to and which I can drop. If you were designing the Iphone in 2005-6 and you got the feedback that it was alien and weird, you should ignore it: nobody had used a phone even remotely close to it at that point, of course it's going to be strange.
• I then start designing the UI of the project, on paper or in Adobe Fireworks
• I keep users in the loop when designing the UI, by presenting them mockups, asking them questions like "if you wanted to do X, where would you click?" and running them through use cases with paper prototypes.
• When I feel that I have not forgotten to consider any significant use cases, and that there are not anymore large, undiscovered features that I think I should include, I can begin coding. Important to note, I only think those things, in reality if this is a great and useful product then there will be some features that pop up later, some ideas that are too good to pass up. The discovery process just minimizes their effect by trying to find most of them up front.
• When the product starts to become usable, I direct my efforts towards completely entire blocks of functionality at a time, meaning say: finish the address book first, then go on to the web browser, then text messaging. This way, I can bring usable portions of the product to users for testing and feedback.
• Repeat until you and the customers are pleased that the product meets their needs and is usable.

The key point of this strategy, and the key to alleviating all your worrying about whether or not you're on the right track or missing something is this: keep the user involved.

Always have an upcoming customer/client demo or interview on your calendar. This strategy does not mean you let your customer drive; if they knew what they were doing they wouldn't need you. It does mean that you let them sit in the passenger seat, however, and you keep listening to them. Keep them in the loop and you will feel more comfortable that you are headed in the right direction.