NEW YEAR'S WISH!

[Peter Walsh]

Here's my New Year's wish........
I wish (and hope) that the hard-working Thermwood team of programmers would stop introducing new features for a while and get the existing software V5 running solid and without quirks. To move ahead when there are so many devils running around in the present version just causes some of us to lose confidence in the software as a serious business tool.

An example is the errors we have all experienced in the board stock summaries and cut lists. Having this output inaccurate is a potential big expense when you bid a job using the software output. Let's get V5 cleaned up! I, for one, will be glad to wait for new features.

Hopefully, all those who agree will sign on to this message.

Regards and Holiday cheer to all,

[Brian Bauer]

Me too I echo peter's sentiments on the little bugs and gremlin's.

But at the same time I would like to express my extreme satisfaction and humble thanks to all of the hard working folks at Thermwood Corp.

And would like to wish all a Merry Christmas and A Happy New Year, and a most prosperous one at that I might add.

Brian Bauer

[Mark Taylor]

I'm in as well...obviously for many of us this is a buisness tool. Not that I think Thermwood is necessarily overlooking the little things or that I should know how long they take to get resolved....but things that worked before should have an emphasis on getting repaired quickly.

I wish everyone a very Happy Holidays and also would like to express my thanks to the Thermwood team for all the fine work they have done to date!

Mark

[DanEpps]

I will agree as well but I also would like to temper that with 30 years of computer industry experience behind me.

In defense of the Thermwood development staff I can personally tell you just how difficult it is to continue adding features to a software package.

You often get to the point where an added feature that works great in itself, causes unexpected results in another seemingly unrelated area of the program.

This is because the original project scope did not take into account these unforeseen (at the time) features and the software was designed accordingly. As the software matured and the user base requested features they needed, Thermwood complied. This is what happens when a great company like Thermwood creates a great product that users love.

This works well for a number of enhancements but you eventually reach a decision point of whether to continue enhancing the current design or create an entirely new design.

It is very easy to simply state \"create a new design\" but you have to recognize the tremendous investment Thermwood has in the current design. If they were to scrap it for a new design I cannot see how they could afford to continue to offer the software without cost.

Forgoing the issue of how costly it would be to redesign the software, there is the time factor. Something as complex as eCabinets cannot be redesigned and developed in a short time frame. It would likely take scores of programmers two years or more to get the first version of a redesigned product ready for beta testing. After another year or so of correcting issues discovered in beta, the product would finally be ready for launch.

This all sounds okay except for the fact that I left out one thing--who maintains the current software while the new product is being developed? Does it get placed on the back burner and left \"as is\" during the development period? Probably not because we, the user base, would not allow that to happen. We would simply abandon ship and start using another software package.

Now what does all of that have to do with my opening paragraph? Everything! I agree that the irritants (large and small) in the current implementation should be addressed before any additional features are considered.

I also urge Thermwood to consider whether the current design can be further enhanced without a major redesign effort. If the answer to that is \"no\", then I would like to see enhancements to the current design locked. If there is going to be an effort to redesign the software, let us know.

There are plenty of items on the wish list already and a new design could take into consideration future modular growth of the software where each module can function independently of the others, needing only a common core module.

With few exceptions I am happy with the current functionality of the software. There are some things I would like to see improved but I do think they are better left alone for the time being.

[Grady Pinckard]

Amen Dan.
Grady

[Rick Palechuk]

Merry Christmas everybody! I agree, lets square up what we got first.

[Ken Susnjara]

I wish it were that easy. As Dan said, whenever you touch any code you risk breaking something else. Even fixing a bug can cause bugs somewhere else. To address this we have a two prong approach. First, whenever we learn of something we broke, it has top priority and we try to fix it immediately. That is why we had so many builds so fast, fixing things the last build broke. The real answer however, is to test everything including everything that ever broke every time you make a change. This will amount to tens of thousands of tests each release. In case you think this is not possible, we installed regretion testing software last summer and have already programmed hundreds of tests that are automatically performed each build. Over time we will add more and more tests including every problem area that pops up so that when you have a problem, it should be the last time. Programming this software is time consuming but we are investing the time and if it works as we hope, the software should get better and better as we add more and more tests. The answer, however, isn’t to stop adding features or trying to make the software better or easier to use. We are trying to strike a balance between fixing what we have, improving what we have and adding new things. To make progress you can't stand still, you have to try to move ahead and do better in the future than you did in the past.

[Peter Walsh]

Ken,
Many thanks for jumping in here. None of us disparage the effort and all of us appreciate the whole scope of what you guys are doing. Really, we do.
Your explanation of the behind-the-scenes-efforts is a help for us to know things are really on track after all, and none are lacking of the courage to push ahead.

regards,

[Paul Huff]

Why I love the software and one thing I did during the holidays.

I have wanted to try this out and finally got a chance. The tricky part for the CNC is the top crown. But I have already generated the CNC file from the profile modeler. We are getting some MDF ready to try cutting tomorrow just for a test. We have already made the corners from the Thermwood rental program. I drew a lot of the pieces with Turbo Cad Deluxe ($100) and loaded dxf files directly into the part editor. None of this could be done without version 5 software. So thank you all for making it possible.
We are not finished with this but well on our way. It is a work in progress.
Paul Huff with Stricklin Builders Inc.

[DanEpps]

I have to echo Ken's response about regression testing--it IS difficult to cover everything in even a simple application.

Let me give a short explanation of software testing to those that are scratching their heads right now.

There are two types of testing performed during development of any software package: unit testing and regression testing.

In unit testing you test the component you are developing for operational errors but it is not tested for compatibility with the entire software package. The component (or unit) can work perfectly in a stand alone fashion but still fail when integrated into the application.

Regression testing takes the entire application with the new (or modified) unit and runs an exhaustive set of tests on the entire application to make sure the new code doesn't break any old code.

It is extremely difficult to identify every possible combination of events that the application can perform and test those events. This is why it is imperative that everyone report not only bugs/errors, but the exact steps taken to produce the error. It is also very helpful to the programmers to have a copy of the cabinet that generated the error.

With this information the regression testing software can then be configured to always test that combination of events when a full test is performed on new or modified program code in the application.

Building up this configuration is much like building your library of seed cabinets--if you happen to have maybe 25,000 cabinets in the library. If you make a global change that affects every cabinet in the library you need to verify that each cabinet is still what you expected it to be. This is your regression test.

If you make a change to only one cabinet and verify only that cabinet, that is unit testing. What if the change you make to one cabinet were to affect the entire library and you did not test all cabinets in the library? You would probably make a lot of firewood in the process.

My earlier response made the blind assumption that Thermwood's development staff is also the testing staff. In a situation like this your development staff can easily get overwhelmed with fixes and testing, then you add new development to the mix and...

To be honest I didn't even give any thought to Thermwood's use of a software test suite even though I use one myself in the small amount of development I still do. My last job in the computer industry was in an IT department of about 600 and I simply failed to recognize that Thermwood uses the same tools we did. Sorry Ken, I didn't mean any disrespect to your IT department there.

I will say that for the size company, Thermwood turns out amazing software. Testing that software without a software test suite would be impossible and getting all of the parameters needed for accurate regression testing is a time consuming task.

We, the users, have to provide as much information as we can to improve the test configuration so that Thermwood can give us software that is worry-free.

[Ken Susnjara]

Another note on this subject is that we have people within the software team whose entire job is testing and ensuring software quality. In addition, every software engineer spends a portion of their time testing and the beta team spends a great deal of time and effort helping us. We take this very seriously. If the software has serious quality problems the whole program can come apart and we all have too much invested for that to happen. As Dan said, we need your help too.

[Mark Taylor]

Ken

First let me say thanks for all the efforts from a very fine organization. And I speak from first hand knowledge even though I have been involved for a brief amount of time - my trips to Dale only confirm the respect and effect you have on your organization.

From the posts above, I have to assume the cut list problem's are now something deeply involved in the program code since we have had several updates since the release of V5 and what seems to \"us\" to be relatively simple arithmetic hasn't or can't be resolved.

Obviously, I don't know didly about programming such a vastly complex program...but what I do know is that it is extremely frustrating to those of us trying to utilize the program in a professional, competitive and profitable setting when aspects of the program (specifically those things that worked before an update) create additional time and effort not needed before the updates.

respectfully,
Mark

[Kirt F. Bowman]

Thanks for the info on testing the software. Ken and Dan have it right when you add anything or fix anything it can cause problems somewhere else.
My suggestion for Thermwood would be to strip down all the features to a basic E-cab lite where it is just a cabinet editor with its various tools only, that generates cabinets and assemblies. Make it smaller make it less graphic intense. Just line drawings, cutlists and front elevations.

My 2 cents

Kirt