Knowing when to stop...

[mandelbrot]

Dear All,

 

 

I have a serious affliction that I suspect a lot of you must suffer from ... I Never know when to stop developing! As strange as that may sound, I'm being absolutely serious!

 

For instance, because of the nature of a solution I'm working on at the moment, I have decided to implement a home rolled security. I then thought to myself - that's all well and good, and keeps within the scope of the project, but what about look-up codes? So, I implemented a system to get and set look-up codes as classes. My boss then asked one day - so have you applied the security system to the code-lookups? I thought: 'No I haven't - that's a good idea!'. So were born access dependant look-up codes. Only to implement them properly I also have to modify my security classes, data classes and user access classes. Then I decided that I needed to alter something else... and so on!

 

All this seems to be taking larger and larger chunks of time, and getting more and more complicated.

 

A serious case of scope-creep!

 

Who else out there has this serious affliction, and how do you deal with it?

 

 

Look forward to your answers!

Paul.

[Cags]

Hehe, I know exactly what you mean, as one microsoft executive said when they were working on last round of .Net Development, "you know, release is a feature too".

[mandelbrot]

LOL! :D

 

He's not far wrong!

 

I seem to get lost in the maze as well, sometimes! There's a couple of times I've caught myself coding a circular reference and have had to review the way the classes and projects all work together, sometimes requiring the movement of several classes between projects! (LOL! Doesn't that smack of bad design!!!)

 

But, I suppose that when you first set off with the basic design spec you think to yourself - 'This is gonna be a doddle!' By the end of the week you've got a releasable version then you think - 'Ah - I think I should implement such and such - it'll make it perform better and be more tailorable!' And that's just about the point when the midden hits the windmill!

[Cags]

I can personally spend days working on a project without adding functionality. I tend to spend hours refactoring in various differen't ways without being able to decide which is the best.

[mandelbrot]

Yeah - know what you mean.

 

The current project I'm working on started out as a small scale thing. I thought that it would be fairly straight forward - learn .NET, write a project... How wrong I was!

 

So far I've spent most of my time writing a library of .NET utility classes. The underlying solution is still there, but each of the projects that make it up are turning into monsters! I think I need to break them into separate solutions. The only problem then, is that they are dependant on eachother!

 

Hell, I think I should take a course in spaghetti management!!! ;)

[Nerseus]

Yep, changes happen all the time and you can't always predict them. Don't get caught up in over design (paralysis by analysis) on the next project simply because you want to prevent the problems you had this time around.

 

Sounds like you're going through the startup troubles of an early phase of development - building that "framework" of what you use. Lookups, including "all access" and "secured access" differences, are "core" and can be reused on other projects. So yeah, having to change your classes, archictecture, etc. is a pain but it's a mostly one time thing.

 

Wait until you decide that cacheing lookups locally sounds like a good idea - another change. Then you'll think "hmm, I can also cache them on a webserver so I don't hit the DB so often" - another change. Then you'll realize that some lookups can be added to "on the fly" so you need a way to clear the cache or alert clients to re-get their lookups when additions occur - another change.

 

Even simple things can change over time - don't worry about it! If you have good classes now, keep it up - keep the changes in "good" condition. You'll almost always regret it if you try to skimp.

 

Of course, there's also the rule of KISS - Keep It Simple Stupid/Silly (depending on the G vs. PG rating). In other words, maybe the lookups could be hard-coded in a class and not read from a DB at all.

 

Part of all these choices and designing/coding for them moves you up from a developer to an architect - a good chance to ask for a raise :)

 

-ner

[mandelbrot]

I nearly had to put my fingers in my ears and sing "La-la-la-la" when you were talking ther, Nerseus!

 

You've pointed something out that I'd actually forgotten about (but would have cropped up on near the end of the development!), something that I've got running already, and something new which would be very useful! The good, the bad and the just plain ugly all in one post! ;)

 

Yep - I've considered embedding values, but it seems like a cheat, really. In one case I have used this method, as their are only a finite number of possibilities, but in practically every other case I've had to use look-ups/references. It works for me, but is starting to get complicated with regards to implementing security etc on the codes themselves.

 

Thanks for your positive words, Nerseus! :)

 

 

Paul.

[mskeel]

Coding Ain't Done 'Til All the Tests Run.

 

I generally try to have projects always in a working state -- spend a little extra time writing unit tests and testing in general -- and I don't add new features until the current set of features are working and stable. Constant refactoring, as Cags said, is also critical and can only be done with confidence when you have automated tests in place. When you approach things from this perspective, if you don't have a discrete feature set, you reach a stopping point after each completed feature and you're "done" when you run out of time or money (client tells you to stop).

 

I think open ended projects are great because you usually get to do a lot of fun stuff you wouldn't normally get to do (what some might consider developer gold-plating) but my experience is that it is especially important to deliver on these projects to make sure you can have a loose leash for future projects. Having an "always a working build" mindset lets all of that happen. And if you end up running out of time in the middle of implementing newest feature X, so what? Just roll back (using your version control system) to the last stable version and give that to your client.

[irasmith]

This is such a good thread of thoughts and comments, I am thinking that we have all been there on more than one occassion.

 

In my early days of programming, I would just sort of take off doing steps to generate the code and all along the way thinking of ways to improve it and would just start off on that as well.

 

Now that I have gotten older, and hopefully wiser, I have sort of trained myself to resist the initial urge to continually improve. What I do instead is make notes that get worked into a plan of future release so that I can remember all the cool ideas I had along the way. But I do not stop the intial release to work in some of these cool things.

 

The initial release is always very basic, but solid. Later, as I work on bug fixes or adding in features that others have requested, I re-visit my list and incorporate some of those items as well. It is really a process of incremental growth, but it is designed and controlled growth that permits me to get something out and at the same time work in a cool change or two as well.

 

There are other more formal ways of working toward becoming better at managing the balancing act. One such way is the Agile development concept where you do indeed do incremental development with each release providing some form of functionality to the user. I personally have not actually partaken in the Agile way but I have done a lot of reading and studying on its methods and processes.

 

At the other end of the scale is the document everything in one sitting, design in one sitting, and then code in one sitting, with the fully completed software being delivered in one lump. I will not condem this approach as I have done it many times before and am sure in my programming life I will do it again. But I tend not to consider this the mode I want to do all the time.

 

Being a middle of the road kind of person, I tend to use something less extreme than either of the above two methods. Yes I still do requirements planning and that type of documentation, but instead of attempting to document everything all at one time I work with Use Cases to do somewhat lightweight but still adequate documentation. Later, as I work on the program, things get revisited and details get ironed out for that particular piece I am working on.

 

Just my two cents worth anyway :)

[mandelbrot]

I believe that doing things in one sitting, as you say, does potentially have its merits, though it is a bit of a closed case scenario - once it's finished and put into place it should be re-written if it needs developing further. Solutions like this tend to be of an urgent nature, and I bet there's not one of us who hasn't been in that position and written code on the fly like that! ;)

 

Also, I don't know if you've seen it, but there's a couple of great pieces of software that are a bolt-ons for .NET, allowing you to produce XML commenting for VB and create the .NET style help files:

VBCommenter

NDoc

 

Fantastic little packages that document as you go, and best of all, they're both free!!

[Diesel]

My philosophy is keep going until you can't stand it anymore.

 

I like to plan ahead. Get all the tools you need in place, and make sure you have a nice quiet place to get to business.

 

Past experience is key, you have to know when to stop and when to expect interruptions.

 

Once you've gone through process a few times, you eventually get the hang out of it and you can stroke one out in under 15 minutes.

[irasmith]

I fully enjoy evening/weekends when I am at home where without interruptions I tend to work without stopping too much. Many times I'll suddenly find myself very hungry only to realize after looking at the clock that mealtime was hours past due.

 

Projects that I tackle like this are just things I do for myself to learn and explore by. Some think its kind of weird that I enjoy doing this but I just happen to be one of those whose hobby is actually their work and as a result it doesn't seem like work to me at all :)

[mandelbrot]

My philosophy is keep going until you can't stand it anymore.

 

ROFL!! I've got to say that I have considered opening my own coffee shop a few times, but the only thing with that is that I'd probably end up writing my own management systems! :rolleyes:

 

Ira, I used to be very similar to that - I'd come into work at 8:00 in the morning and not stop, sometimes, until 9:00pm. I found that I got less interuptions after 5:00pm. Once I was there until midnight trying to solve various problems... Those ... were the sad days!!! Now, I have a life! Sometimes work has to be left at work!

 

 

Paul.

[mskeel]

I find it is often times harder to find a stopping point when pair programming than when flying solo... ;) I've never actually done more than a few 100 lines of code pair programming but it was mentally brutal. When you got tired you'd just switch off and kept going. And it always seemd if you were tired, your partner wanted to keep going. Luckily, as I said, all the projects I've done in pairs turned out to be relatively small, but they were brutal. I suppose this isn't so much feature creep as it is just coding 'till you're brain dead.

[Diesel]

I'll pair program with you Mskeel :)

 

Wait...yeh sure why not.

 

I'll program, you can rub my belly.

[mandelbrot]

I've got it everyone! I've discovered when to stop!!! I now stop ... wait for it ... WHEN SOMEONE ELSE TELLS ME TO STOP!!! It's great! Try it sometime!

 

;)

[Eduardo Lorenzo]

Yeah.. I have "tried" to stop.. am still trying to stop...

 

thing is.. (now THIS I know many will relate to) there are times when like when your driving, eating, taking a bath heck even when sitting on the toilet.. when a "better" approach to the system that you are currently developing suddenly pops into mind??? HEHEHE! get it?

 

darn countless are the times when I had to cut a shower/snack short jsut to jump right back at the keyboard. :D

[mskeel]

darn countless are the times when I had to cut a shower/snack short jsut to jump right back at the keyboard.

Well, I'm glad to see you haven't let programming negatively impact your health or personal hygiene! :D