SeedCode Support Forum

I am pointing this question at those who have experienced the same problem as I have just lately.

Having purchased the full value of CC Calendar, I have developed what is fast becoming a quite complex and sophisticated application for managing my job as a teacher.

What started out asa basic lesson management application has grown into managing behaviour, pupil records, assessment, lesson evaluation, detentions etc etc

I have added about 40 new layouts and i think 10 new tables as well as new instances of existing tables.

I am currently adding the bells and whistles that would make the program outstanding rather than brilliant. Howevr I am (and i know it is my own fault but i am a novice) in the situation that decisions taken when addin the first few scripts, tables and layous are making it difficult to impleent easily some of the more complex functionality.

I now know how to "do stuff" much more efficiently and elegantly and am wondering hether to soldier on or to start over and do what i sould have one from the start.....document, design and best practice.

I kno it is impossible to comment on my situation, but for those who have "sarted over", was this the right decision to did you regret it?

Should i start over?
Should I try to tidy up what I have what I have? (it is reasoanby tidy i think)
Should i get a copy of Inspector? (wil this improve my life)

Any advice / comments much appreciated.

Thanks

Brian

Hi Brian,

Great post; thanks.

For what it's worth, I'm a big fan of starting over. In the course of building our calendar applications I get to start over every year or so and I always find-- just as you've suggested-- that I can make the application leaner and easier to support with each successive revision.

I think there are just a couple things to keep in mind.

When to Start Over. One of the reasons you give for starting over is that you're more experienced now. Undoubtedly. But that's never going to change, hopefully we're always getting smarter. At the same time, our peers are getting smarter also and its worth looking around to see how the community of consensus is building around topics you're interested in. A couple examples. It's taken over a year for folks to figure out how revolutionary the web viewer really is (take a look at some of the plugins an java stuff released at DevCon): in that light, we're probably just now starting to see what we can do with the new conditional formatting in 9. When looking at it this way, waiting to start over is about not only your own education, but that of your peers. So, part of starting over may be waiting to start over: and that means you just have to "know what you're building".

Know What You're Building. The decision to start over sometimes just means recognizing that the file you're working on may just be a prototype, not the "final" file. This can be very liberating and let you focus on what a prototype is good at: teasing out where your design and your customer's / your requirements mesh and where they don't. Seen this way, you get a different sense of "what needs to be done before you start over."

What Needs to be Done. Everyone has a different sense of this, but in our practice, we've found that you don't really know if you've gotten it right until the reports are done. Reports tend to be the place where you find out if your architecture fits the clients requirements easily or if your architecture choices make certain things harder (or slower). Find this stuff out now, before starting over. This means you can take a lot of shortcuts in the prototype (hard coding value lists, for example) to get working reports fleshed out.

The Second System Effect. There is an axiom in software that the 2nd version of something tends to be unnecessarily complex- there are probably a lot of psychological reasons for this, but just guard against it. Starting over should be "simplifying" whenever possible. A couple things to read on this topic if you haven't already would be Systemantics and The Mythical Man Month. The former is less well know but seriously on point.

Inspector Will Improve Your Life! Definitely.But it doesn't necessarily do what we want it to; for example, it is very hard for something in FileMaker to be actually "unused" (ie. completely unreferenced by anything else, even its own auto enter calc and absent from all layouts). So things like Inspector are best for errors and dependencies. If you have a tangled mess of a file, it can be hard to ask Inspector what you can safely delete-- though it does help with this. This is partly why we like "Building vs Cleaning".

Building vs Cleaning. Our ad in the DevCon binder included this quote from the Mythical Man Month...

System BUILDING is an entropy-decreasing process.

Program MAINTENANCE is an entropy-increasing process, and even its most skillful execution cannot change this.

True indeed. To some degree this means that even if you want to tidy up what you have, you may not be able to. Now I may be more skeptical than most on this point, but I think what all this means is that if you have an opportunity to start over, you should.

This is an excellent post! Might be worth making it sticky.