Getting Obsessed with Perfect Design

Call Me Jimmy

Hi Guys,

I've been having a problem in the last year or so and it's not strictly a coding problem.

I start out with some whiteboarding, say a feature that I want to implement. Do a couple of use cases and then some very basic object diagrams. Once I feel I have an idea of what is going to happen I try code it and this is where the problem starts.

I just infinitely begin generalising what I'm trying to do, trying to get the perfect system. I may know how to actually implement something, and could technically do it in a day but not in a good enough way. Say I wanted to have a simple scrolling game, I know how to move things across the screen but I begin trying to design almost an engine that could be used for scrolling any direction (just in case I needed it in the future). That's just an example.

The more I try to write it the more I try to get the perfect code and a workflow from feature design to implementation becomes non existent. It's hard to explain really.

I'm wondering do other people have this problem? Also if anyone has any good recommendations for a workflow, I have a fair idea say about agile and tdd, but I've found it hard to get back into things after a 6 month break from programming. Language specific stuff isn't really a problem, but taking a system from design to implementation is proving to be impossible for me so any advice or links would be appreciated (I know it's a broad subject).

ChRoMe

Call Me Jimmy wrote: »

Hi Guys,

I've been having a problem in the last year or so and it's not strictly a coding problem.

I start out with some whiteboarding, say a feature that I want to implement. Do a couple of use cases and then some very basic object diagrams. Once I feel I have an idea of what is going to happen I try code it and this is where the problem starts.

I just infinitely begin generalising what I'm trying to do, trying to get the perfect system. I may know how to actually implement something, and could technically do it in a day but not in a good enough way. Say I wanted to have a simple scrolling game, I know how to move things across the screen but I begin trying to design almost an engine that could be used for scrolling any direction (just in case I needed it in the future). That's just an example.

The more I try to write it the more I try to get the perfect code and a workflow from feature design to implementation becomes non existent. It's hard to explain really.

I'm wondering do other people have this problem? Also if anyone has any good recommendations for a workflow, I have a fair idea say about agile and tdd, but I've found it hard to get back into things after a 6 month break from programming. Language specific stuff isn't really a problem, but taking a system from design to implementation is proving to be impossible for me so any advice or links would be appreciated (I know it's a broad subject).

I find deadlines remove this problem extremely quickly! Nothing like a stressed project manager to bring out the pragmatist in a developer.

Call Me Jimmy

Currently unemployed :P

c_man

No I don't have that problem. I've been fixing bugs for so long, can't remember what feature development is like

Yeah OP I know what you're talking about, but work time constraints put a dampener on anything like that.

Colonel Panic

More than one XKCD fits here but I'll write a proper post.

The two hardest things I've had to learn as a software developer were how to deal with non programmer's expectations and how let things go and not try to write "perfect" code - There's no such thing and no one but you cares.

Writing a generic solution to a specific problem is stupid. Thinking the main reason for OO code is reuse is a mistake. If you can reuse code later to make a generic solution, that's so much better.

All the best code I've seen is an evolution of crap or simple code. You're not writing this stuff on stone tablets to be handed through the ages, it's there to do the job so use it to get the job done.

Getting the job done might often mean bad code, but people learn from their mistakes and a lot of it ends up being down to experience and intuition. That's what takes years and years to learn. I still write terrible, impossible to maintain code. I maintain code by people who had more experience than me and the WTFs fly liberally.

Some links to start your research:

http://en.wikipedia.org/wiki/Worse_is_Better
http://en.wikipedia.org/wiki/Principle_of_good_enough

Also look at the paradox of choice. Not development per se, but too much choice tends to make choosing more difficult imo. Given all the dogma around the "right" way to code these days, it doesn't surprise me that people sit at their IDEs paralysed.

GreeBo

Deadlines do certainly help...also I think it's just a balance between being cognizant of the future use cases but also watch that you aren't entering the realms of preemptive optimisation...

Helpful for me is to get something that works and then re factor to make it nicer...that way you always have some version that works to fall back on when the PMs come looking!

Aswerty

I think a good way to look at this is that a perfect design is one in which you can add that extra functioinality later with ease but you don't actually build for it. So your code is specific but extensible. This extensibility should placate the architect in you. The SOLID prinicples are a good rule of thumb in terms of how to build extensible software.

Also if you are building a scrolling game and you end up being more interested in the game engine it might indicate that it is the game engine you are more interested in. So maybe scrap the game and build an engine. You can always make a game with it at a later point. Remember that most games use an engine so if you build one without one you're going to keep running into places where you'll find the lack of an engine restrictive. I imagine people building web applications without a web framework bump into the exact same issue.

Also your question pretty much asks "how do I stop myself from doing what I choose to do". The answer is pretty bloody obvious, find the motivation to do what you originally set out to do. Also I find over generalising architecture is an indication of weak design skills. It is comparable to over quoting on how long something will take (i.e. not enough knowledge to do just enough to deliver). So keep that in mind when building your next project.

Giblet

Ah, the ol' analysis paralysis.

It's best to think of oop as a way to encapsulate code so it can be refactored effectively. Trying to actually solve the problem in the perfect way first time is a way to get nothing done at all. You just need to be able to quickly refactor mistakes upon deeper insight.

ChRoMe

Colonel Panic wrote: »

Writing a generic solution to a specific problem is stupid. Thinking the main reason for OO code is reuse is a mistake. If you can reuse code later to make a generic solution, that's so much better.

Quoted for truth. Generally when I have something to write I just start writing it, straight out of the top of my head. The first step is to just get it working, the structure can be a complete mess, thats ok for the first draft. Once I'm at that stage I go back through the code and do the obvious clean ups. Obviously nothing too embarrassing gets committed!

Once you start going back and dong the initial clean up the optimisations and places where generics can be used become more apparent. Its a very organic process, similar to a fiction author writing several drafts.

Call Me Jimmy

Good replies so far!

It seems I have too much theory in my head, patterns, a billion design principles, lifecycle management and also the actual systems/products themselves, how to solve the problem.

I have only been getting back into this whole thing a week ago so I knew it might be rough, but I do remember having this problem to a lesser extent in my college days.

There are just so many theories to how to best design and develop software I wish I could find one that I could give divine faith to.

But from what you guys have said, and seeing as I'm kind of re-learning stuff, I will up the discipline and let this first project back be a build refactor type deal. Rather than looking ahead and trying to see everthing from the beginning. For example, I may have a decent conceptual understanding of the system but I haven't been giving myself room for what the reality presents.

Do people have a general workflow, based on experience, that incorporates the design of a fresh system? In rough terms, what would be your steps?

e.g. 1. Take a list of features and create stories.
2. Take important actors in stories and make object diagrams...

that type of thing, what did you find were the best preliminary activities before coding that helped design?

Call Me Jimmy

ChRoMe wrote: »

Quoted for truth. Generally when I have something to write I just start writing it, straight out of the top of my head. The first step is to just get it working, the structure can be a complete mess, thats ok for the first draft. Once I'm at that stage I go back through the code and do the obvious clean ups. Obviously nothing too embarrassing gets committed!

Once you start going back and dong the initial clean up the optimisations and places where generics can be used become more apparent. Its a very organic process, similar to a fiction author writing several drafts.

Yes I'm very comforted by this approach. I wasn't sure if professional developers would ever work this way, it's great to hear some do because it actually sits the best in my mind as the "right" way (different for anyone).

But you wouldn't do this if you had responsibility for a completely new system? You would have some preliminary design ideas where you try to plan ahead? Or no?

GreeBo

ChRoMe wrote: »

Quoted for truth. Generally when I have something to write I just start writing it, straight out of the top of my head. The first step is to just get it working, the structure can be a complete mess, thats ok for the first draft. Once I'm at that stage I go back through the code and do the obvious clean ups. Obviously nothing too embarrassing gets committed!

Once you start going back and dong the initial clean up the optimisations and places where generics can be used become more apparent. Its a very organic process, similar to a fiction author writing several drafts.

But, but, but...what about coding to interfaces?!

I'm sure none of us have projects where 40% of the files are interfaces that only have a single implementation... :eek:

ChRoMe

GreeBo wrote: »

I'm sure none of us have projects where 40% of the files are interfaces that only have a single implementation... :eek:

Quite, a lot of people are just fooling themselves.

ChRoMe

Call Me Jimmy wrote: »

There are just so many theories to how to best design and develop software I wish I could find one that I could give divine faith to.

Stop looking, you will never find one.

Aswerty

I think the skill of being able to plan ahead is something that comes with experience rather than learning the "planning ahead pattern". Planning ahead often deals with avoiding pitfalls as opposed to building a perfect system. Also when building real systems planning becomes important but if you are just building stuff to improve your skills and build a portfolio then this planning thing is not all that important.

But, but, but...what about coding to interfaces?!

I'm sure none of us have projects where 40% of the files are interfaces that only have a single implementation...

Personally most times I use an interface is when I want to loosely couple code so that it is more testable as opposed to wanting to introduce another implementation at a later point.

GreeBo

Aswerty wrote: »

Personally most times I use an interface is when I want to loosely couple code so that it is more testable as opposed to wanting to introduce another implementation at a later point.

True, but the mocking libraries are so powerful these days that you can mock out/intercept/whatever *any* class and basically achieve the same thing.

Dependency Injection /AOP is about the only reason left and then I try to do it on demand rather than up front.

+1 on planning ahead. You just learn anti-patterns through experience and what not to do is usually more important that what exact to do.

Call Me Jimmy

I have done a very small bit of mocking before, what would you consider the main purpose to be? To just get results back from other components/interfaces that don't exist yet so a particular component can be tested in it's interaction with unimplemented interfaces?

Aswerty

Can't say I've mocked anything out that didn't implement an interface but a quick google shows that mocking and interfaces aren't as symbiotic as I thought. So that's one useful thing I've learned today!

As to why mock? The purpose of a unit test is to test a specfic piece of functionality. If that functionality makes use of other code which we do not want to test (e.g. database calls or framework functionality) we mock that code out. Unit testing and mocking can become a real chore if code is too tightly bound. If your writing code that you are the only one who is ever going to touch it and/or it is throw away code then writing unit tests can be overkill.

[-0-]

Alright Jimmy. Give this a read. http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X

ChRoMe

While this is specific to game development, it illustrates what we are discussing *perfectly*

http://indiegames.com/2013/04/video_making_a_game_while_stru.html

Call Me Jimmy

[-0-] wrote: »

Alright Jimmy. Give this a read. http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X

Got this, cheers. Seems to be exactly the type of book I'm looking for!

ChRoMe wrote: »

While this is specific to game development, it illustrates what we are discussing *perfectly*

http://indiegames.com/2013/04/video_making_a_game_while_stru.html

Gonna read this.

I had a better day today, thanks to this thread. I set myself a piece of functionality, whiteboarded only what it NEEDED to do. I wrote it by writing the test for it and it worked well. I had more discipline. Followed that with an exploratory bit of code, as in, starting to write code for another piece of functionality (which uses a library in a domain I also have to relearn) and will refactor as I go.

Looking forward to reading/watching the yolks above. EDIT: Funny I have been diagnosed with a specific type of OCD. Not sure how much I believe it but coincidence all the same!

ChRoMe

Call Me Jimmy wrote: »

Got this, cheers. Seems to be exactly the type of book I'm looking for!



Gonna read this.

I had a better day today, thanks to this thread. I set myself a piece of functionality, whiteboarded only what it NEEDED to do. I wrote it by writing the test for it and it worked well. I had more discipline. Followed that with an exploratory bit of code, as in, starting to write code for another piece of functionality (which uses a library in a domain I also have to relearn) and will refactor as I go.

Looking forward to reading the yolks above.

Sorry, the content I was referring to was the 30 minute video, which is well worth your time.

Call Me Jimmy

Yes will watch it defo!

Colonel Panic

Just finished watching the video. Very interesting to watch. Liked the guy's honesty and it's something that I think resonates with a lot of developers.

ChRoMe

Colonel Panic wrote: »

Just finished watching the video. Very interesting to watch. Liked the guy's honesty and it's something that I think resonates with a lot of developers.

Yeah a nice real world example of the age old adage "Perfect is the enemy of good".

I find myself shouted down by even more senior developers when I try to present a bit of pragmatism in professional situations. There is a *huge* amount of developers, far more technically skilled than me, that just don't grasp business/reality consequences because they are too close to the code.

GreeBo

Aswerty wrote: »

Can't say I've mocked anything out that didn't implement an interface but a quick google shows that mocking and interfaces aren't as symbiotic as I thought. So that's one useful thing I've learned today!

Yep it used to be a real issue (same with final & private classes) but now with runtime bytecode manipulation (I'm assuming) its open season!

Sparks

Call Me Jimmy wrote: »

There are just so many theories to how to best design and develop software I wish I could find one that I could give divine faith to.

Please stop whatever you're doing and go watch this:

http://vimeo.com/9270320

For me, hands down, that is one of the best talks I've ever seen given on the problem you're describing, and it's one of the ones I'd recommend anyone - whether they've been coding for ten years or ten days - to go watch. But especially anyone looking at what you just described there.

Trojan

Sparks wrote: »

Please stop whatever you're doing and go watch this:

http://vimeo.com/9270320

For me, hands down, that is one of the best talks I've ever seen given on the problem you're describing, and it's one of the ones I'd recommend anyone - whether they've been coding for ten years or ten days - to go watch. But especially anyone looking at what you just described there.

Awesome video.

[-0-]

Is this the book he's on about at the end of the video? http://www.amazon.com/Making-Software-Really-Works-Believe-ebook/dp/B004D4YI6G

Call Me Jimmy

Hey guys, last two days have been MUCH improved. I still catch myself getting hung up a small bit and am able to stop it. Watched the first video yesterday very good thanks! Will watch that latest video today.

I've been going through the book tie fighter recommended and just copy and pasting lines that resonate or I feel are important into a text file that I give a read over in before doing any work.

It has been really good so far, before this thread I knew I needed to change as I had two days in a row where I basically got NOTHING done. Keep the tips/videos coming I'm enjoying them!

Sparks

[-0-] wrote: »

Is this the book he's on about at the end of the video? http://www.amazon.com/Making-Software-Really-Works-Believe-ebook/dp/B004D4YI6G

That's the one. Sitting half-read on my desk at home (toddlers slow your reading pace down a lot).

Also, read his website http://neverworkintheory.org/
It's the actual papers and comments behind all of this.