Every time I develop add features to my C# remoting distributed LLBLGen win/webform database application, I end up spending all of my time abstracting those features to ancester classes. It seems that I won't be happy until every fully functional form can be added to the application with simply a call to the form's constructor (and perhaps an interface or two).

Am I crazy?

Jeff

Could you elaborate a bit on the problem, because I don't have a clear picture what the problem is (perhaps it's because I have not yet a clear understanding what an ancestor class is )

Today I was working with a windows TabControl in a parent-child capacity wherein the first tab contained the parent EntityCollection and the second tab contained the children EntityCollection for the selected parent record.

I wrote a little code that prevents the second tab from being selected if there was no selected parent record. No big deal.

Instead of moving on the next part of the project, I decided to build on to the TabControl and create a custom tab control that encapsulated this simple parent-child behavior so that by merely dropping this new custom tab control onto a form, this behavior would happen automatically without having to write the simple code for every parent-child form.

Unfortunately, encapsulating behavior on top of behavior into derived custom controls has gotten to be an obsession. I spend more time adding this kind of functionality to the application framework than actually progressing with the application itself.

Is this crazy?

Jeff

In my opinion, I do not think you are crazy. It depend and you are the only one that can answer the quesion. To help, here is some ramblings.

Design in IT is making comporomises here and there depending on business priorities and needs.

For example, are the business priorities maximum re-use, scalbility, performance, secutiy (in this order) ? In this case, because performace in near the bottom of the list of priorities, you would develop in true oo with mamimum abstraction. However, if the priories are in a different order, then your solution might be a bit different.

In the example you give, it seems to me that turning that functionality into a component enables re-use by less knowledgable people in the team and therefore enhances consistancy, and significantly reduces costs - no learning curve and minimum maintence.

So in the scheme of things, spending a little more time developing re-usable component is extremely usefull and helpful to the project in my opinion.

You should pat yourself on your back.

sparmar2000 wrote:

You should pat yourself on your back.

Very nice of you to say, thanks. However, instead of adding the two-line code on to each of the forms that require the aforementioned behavior, I took all afternoon designing and debugging a custom tab control.

Now, I have a cool custom control that I can drop onto a form that automates a task that previously took two lines of code to implement.

How far is too far?

Jeff

Yes but...if these 2 lines were in many...many forms and you wanted to make a change after you have gone live...it is easier changing the control rather then many pages and testing...I would have thought!

How big is the team and your project if I may ask?

My team is me. The project is huge:

It's called the Proximity System (www.unitec-corp.com) and I'm porting it from a Delphi ver 5, WebHub solution that is about four years old.

The Proximity System manages uniform apparel distribution for organizations that have uniformed employees and remote inventories scattered over many remote sites.

Not crazy, just procrastinating. You're diverting yourself and trying to justify it by calling it 'useful'. There's something difficult ahead of you and you don't want to face it.

I remember someone on this site pointing out that the hardest work they do all day is simply starting. After starting everything is easy.

Face what's ahead of you. Make some lists of the work that needs to be done. Identify what's critical. Try to break each goal into small, discrete tasks, and tackle those tasks one at a time. Reward yourself for each small task, and eventually those rewards pile up.

Get 'er done!

Interesting take. Procrastination takes some very interesting forms!

Jeff

swallace wrote:

Not crazy, just procrastinating. You're diverting yourself and trying to justify it by calling it 'useful'. There's something difficult ahead of you and you don't want to face it.

That was also the idea I got . It's key to stay focussed, even if it's boring and dull at times. To help you: I have the same moments, where coding is simply dull and boring (imagine porting 70,000 lines of code to .NET 2.0 and you have to refactor every arraylist usage and hashtable usage into generic types etc. ). Though once you've started, and some of the stuff is done, you'll be seeing the end of the tunnel . Remember: also the boring stuff has to be done, so better do it first than last.

Otis wrote:

I have the same moments, where coding is simply dull and boring (imagine porting 70,000 lines of code to .NET 2.0 and you have to refactor every arraylist usage and hashtable usage into generic types etc. ).

Then you should write a tool to parse your code and do this port for you. (GDRVVF)

BOb

haha yeah, I really didn't see that one coming

Yes, Every "real" programmer will spend days programming a tool that will automate what the could have done by hand in hours. And then come the enhancing and debugging and the situations that are kindof the same but different.

arschr wrote:

Yes, Every "real" programmer will spend days programming a tool that will automate what the could have done by hand in hours. And then come the enhancing and debugging and the situations that are kindof the same but different.

Heh. Actually, I've seen people do that, where they spend literarly weeks on a tool which saved them 2 days of work.