Leaderboard

This is the best book I've had the pleasure to not read. The cover is definitely quite reddish. Is that a reasonable review? Also, for the other review, all you need to do is use MAD magazine's approach to advertising and read it like this:

That would be a lumbar microdiscectomy, to be exact. Yup, today I am getting my back opened up and parts of my spinal column removed. I have had a herniated disk (well, a couple actually, but only one that's currently causing a lot of trouble) for almost a year now. It was bad, got better, then at the beginning of last December got much worse. I have been thru therapy, oral steroids, epidural cortisone shots, etc. Nothing seems to be working, so it's time to get out the knife. I am currently on more opiates than House. The big difference between me and House, tho, is that he's a fictional charcter and doesn't actually feel pain. I, on the other hand, still hurt like h3ll. Hopefully that will be all over in a few hours. Well, mostly over anyway, as I've been told there has probably been nerve damage and there will be residual pain/tingling/numbness from that for quite some time. But it should be much better than it is now. I'm not sure what the recovery time will be like. I can't come back to work for 2 weeks. I'm not supposed to sit for more than 30 min at a time. At the moment, sitting is very painful and I'm lucky to get 10 min in a chair before the pain becomes too severe. That would be why I haven't been on LAVA much -- it's hard to type when you're walking around. This is a routine procedure (for my surgeon, anyway ) and if all goes well I should be back home tonite. Keep your fingers crossed for me! Cat

Making customers pay for bug fixes is indefensible. Making a bug fix release that trashes your installation because you haven't paid is just plain boorish.

I don't disagree with you. However, many small simple solutions put together doesn't necessarily equate a simple overall solution. But that discussion is way off topic so I'll do something really unusual for me... I'll stop.

Hey John, are planning on starting a new project or doing a running refactor on your current code? My sense is that a running refactor is technically more challenging but is less risky overall as it offers continuous incremental improvements on existing production code instead of a starting a new dev effort on an incompatible parallel branch. My thoughts and experiences, for what it's worth... Things to avoid 1. Don't try to do a detailed design before you start coding. I have yet to produce a design on paper that didn't need to be altered--sometimes significantly--when implemented. I discovered I spent wasted a lot of time working out details on paper that never got implemented because of a change somewhere else. 2. Don't get bogged down in process. The goal is to develop good software, not develop good processes. Too much process is just as bad as no process. Finding the sweet spot for your group will take some time. 3. Don't be overeager to use inheritance. It is actually a fairly restrictive relationship. Delegating tasks via object composition is a much better general purpose way to reuse code and give an object additional abilities. Things to do 1. Find a development methodology that works for you. There are lots of competing ideas about the "right" way to develop software: Test Driven Development, Agile, Waterfall, Unified Process, etc. In truth, the "right" way is the way that helps you deliver the product on time. There is no single best methodology. It depends a lot on the corporate culture, types of projects being developed, requirement maleability, timeline, etc. I've taken bits and pieces from several methodologies and combined them into an informal process that works well for me in my current environment. Your process will likely be different. 2. Architect from the top down; design and implement from the bottom up. (This point is debatable--every dev has their favorite way to do things.) When I'm architecting the app I break the requirements into functional components and figure out the api for each of those components. Each component then get broken into sub components if the complexity warrants it. At this time I'm just thinking about the component's public interface; I don't worry about implementation details. When I get to the point where I have components with a manageable size then I start implementing code, assembling the components into larger components as I work my way back up the architecture. 3. Decouple the UI. You mentioned using a web front end. It's possible (and not terribly difficult) to decouple your UI from your functional code in a regular Labview app. I get irritated with programs where a simple UI change propogates down into the lower levels of functional code. That's just poor (IMO) design. Plus, decoupling the UI makes it possible to create unit tests at the application level. 4. Dedicate time for refactoring and simplifying your code. Software development is a very organic process. (At least for me.) When I get to a point where a component's public interface works the way it is supposed to, it's not really done. I can pretty much guarantee the internal workings have some extra fat laying around. Take time to do some lipsuction--it'll improve the long term maintainability of your app. Addressing some of the specific items you raised... Design Patterns - One of the best bits of advice I read about design patterns is to "apply design patterns gently." In other words, don't carry around your design pattern solution looking for a problem to solve. Applying them where they are not needed adds a lot of unnecessary complexity. (It's a great way to learn the design pattern, but I have a lot of extra stuff in many of my early applications.) Unit Testing - Contrary to common perception, unit testing is not free. In fact, it is quite expensive. Not only does it take time for initial development, but you have to go in and fix the unit tests when a design change breaks them. When a test run results in a bunch of failure, chances are at least some of those failures are due to errors in your test cases. Every minute you spend fixing your test cases so they result in a pass is a minute you're not spending improving your code. Don't get me wrong; I think unit testing can be extremely helpful and I'm still trying to figure out how to best use it as part of my dev process. But I think it's a mistake to try and create a comprehensive unit test suite. Packed Project Libraries - Some users have reported problems with ppls. You might want to wait a year or two before including them as an integral part of a mission critical app. -Dave