Slashdot Mirror

Do you have any other suggestions for this situation. I'd be willing to bet this is the case for close to 50% of code checkins.

On your projects, perhaps. On mine, never. I use continuous integration tools like Anthill and Cruise Control, and anytime a checkin breaks the build, the developers hear about it pronto. This is a little annoying to start, but once you get broken in it's fabulous: what's in CVS is always trustworthy, and if you see a problem you know it's your problem.

If you're just using CVS to pass around files, then you could just email the files around. If you keep the units of work small, clear, and discreet, this works fine.

Another option is to have areas in CVS for things that are half finished; the person to do the last bit of work moves things to their proper place.

With the designer/programmer split, one helpful approach is to make the last step connecting it to the rest of the app. So if it's a web app, you put up the new pages in a way where you can get to them only if you know the URLs. Then only when they're perfect do you add links from other pages.

You can also make features configurable, so that a feature is only visible if certain configuration options are set. This is especially valuable in environments where you have to roll out multiple related servers but need to bring everything live at the same time.

But my favorite approach is to get the necessary people together in one place. E.g., the programmer pairs with the designer, and you get things done in one go. Not only is it faster and more likely to work, but both sides learn a lot more about how the other guy works.

• Automate your build!
• Extend your build system to include the environmental configuration
• Automatically build separate targets for different environments

Most of the setups I've seen are running CppUnit or similar with Make for builds and tests. Another option is OpenMake

Making that happen repeatedly on a controled server is the domain of Anthill, CruiseControl and a handful of for money tools.

you are shooting yourself in the foot by open sourcing the drivers

That sounds like the case.

As a programmer, I always like the idea of open-sourcing stuff. But from a business perspective, I can only think of two cases where it makes sense. The first is with the parts of your code that you think of as boring, commodity stuff. An operating system is a good example of that; if I have a patch for some Linux thing, I'm glad to share it because the value of a free, community-developed operating system is very high to me, but my slight improvement to it gives my competitors little additional advantage. Other good examples include the stuff from the Apache foundation, like their httpd and Struts.

The other case is where I want to gain mindshare. For example, the program Anthill has an open-source version and a commercial version. People who use the free one are much more likely to buy the commercial one. In essence, they give away the old version of their app in exchange for patches, suggestions, and attention from potential buyers.

So in the case of a hardware vendor like yourselves, you could try this strategy by, say, open-sourcing a basic API layer and related device management tools, while keeping much of your device-related code proprietary. Done right, this could establish a standard that your competitors would have to hustle to follow.

The best example I can think of in the hardware space is the Hayes modem protocol. Of course, it didn't guarantee them success, but the fact that all of their competitors had to put "Hayes-compatible" on their boxes sure didn't hurt them any.

Like a previous post, I'd suggest "evolving" to testability - every time you fix a bug or add a feature, do it test first.
You will have to spend some time setting up the testing framework - a structure for your unit tests, the "non-code" stuff, and a way of finding out asap that you've broken a test.
Depending on your environment, you could use something like AntHill or CruiseControl to automatically run all your unit tests as part of a (timed) build process, and email the results. CruiseControl also allows you to specify regular intervals at which your entire code-base is checked out of source code control, and unit-tested - you get an email if something breaks.
A key problem for most systems is getting all the "non-code" stuff (in my case mostly databases etc.) into a known-good state so you can rely on a unit test reporting accurate errors when trying to insert a duplicate value or delete a non-existing record - again, automate using (something like) Ant - Ant will do a lot of this stuff for you on non-java projects too.
Once you have refactored sufficiently, you can hopefully start testing independently from the "non-code" items.
I'd suggest buying Kent Beck's book "Test Driven Development" for more ideas on how to code in this paradigm - it's very very good.
Another book worth reading is The Pragmatic Programmer (they have a website too). Especially the "no broken windows" section is very worthwhile...

I disagree with the poster in principal, but he does have a point in that anyone who started EJB development at EJB 1.0 was screwed. Suns "Best Practices" at the time led to horrible performance when implemented in the real world. To do a JOIN with entity beans back then meant that the database table information would be queried in a FINE GRAINED manner and passed THROUGH THE NETWORK so that it would appear that the database tables could be manipulated as objects. In essence they wanted EJBs to allow java programmers write database calls without knowing how to write database calls.

EJB 2.0 with newer design patterns has made great strides in performance AND scalability. I won't go into it here except to say that the two patterns that EJB developers should look at are

1) Session Facade - If you don't have a trained DBA on staff, or performance is not as important as maintainability.

2) Course Grained Session Beans - If you do have a DBA, and/or you need the best performance.

look here for a good EJB patterns benchmark

look here for a free book on EJB design patterns.

Even more important is Anthill's support for multiple projects, complete with dependency graphs. Support for multiple projects is such a must-have feature (for me, anyway) that choosing Anthill over CC was a no-brainer. It's even open-source, so you can tweak it to your heart's content.