Showing messages 1 through 6 of 6.

• I take it all back :D
  2007-07-24 17:53:06 rickcarson [Reply | View]
  
  

  I talked to one of the developers at work last night, and as we were talking she was trying to do some debugging. It looked like one of the libraries had gotten out of sync, so she had to do a clean and install. 20 minutes later it was still going.

  Part of the problem is they have all these 'helper' utilities that are there to ensure 'code quality'. So that _every time_ they do a build all this other stuff kicks in, massively slows down the process and kills their productivity.

  If my home process was anything like what they go through at work I'd have thrown my computer out the second story window. (Which would be an excuse to upgrade the Mac :D - it still works fine so I have no reason to upgrade except for techno-lust for the latest models ;-)

  Quick quiz: what is wrong with the following code: for (int i = 0; i < maxSize; i++) { System.out.println("Hello " + i); }

  Although this is really standard code and only three lines long, it would have violated not one, but _two_ of the checkstyle rules they have to put up with. Amazing. (And probably a third, given the anality of the rules they'd probably spit the dummy at adding a number to a string)

• Really not surprised with the results
  2007-07-22 14:55:58 cajo [Reply | View]
  
  It is an interesting question, certainly.
  
  At home, one has complete control over the tools and methods one uses; not so at work.
  
  Therefore; if one has an inferior software development environment at home, one must ask: Why?
  
  In days past, this could only be attributed to the cost of buying good software development tools. Today, this is no longer the case.
  
  John
  
  
  
  
  
  
  
  
• Really not surprised with the results
  2007-07-23 06:33:16 writtmeyer [Reply | View]
  
  John, I do agree with you. You have the ability to build an environment that fits exactly your needs.
  
  But still: This does incur some costs, most of all a lot of time. So if you do not actually _like_ administrative fiddling you might actually prefer your work environment even if some things might actually annoy you.
  
  Another point which could be better at work is the availability of certain types of hardware you like. Any mainframe at home? Well I don't. Ok, _I_ do not miss it, not at all, but others might.
• Really not surprised with the results
  2007-07-25 16:33:20 sinewalker [Reply | View]
  
  hmmm.
  
  The question is about the process though, not the tool chain. If the only problem I had at work was wrestling with the tool chain, then I'd actually rate both about the same, since each environment still involves a bit of fiddling to get things running smoothly (except for MS VSS, which I just want to replace entirely...).
  
  The problems at work which I face are more along the lines of rickcarson's observations (except that the anally retentive code "quality" is "enforced" here by peer review only, not a code lint...). We have much more basic problems, such as, insistence on a waterfall approach to everything, no test-driven programming (and no budget or interest in building a unit/regression test suite), no control of requirements and no structure in determining them. To some degree our customer even designs and dictates the solution (?! disaster !).
  
  At home, I can control the development process, adopt rigorous test cases and do peer programming via IRC and email. I can use the (radical?) idea of use-cases and some UML documentation instead of trying to retro-fit 1970s "structured analysis/design" methods and documentation to an OO project... This is basic stuff that has little to do with the tool chain, and more to do with being in a huge, inflexible, beaurocratic monolithic dinosaur company.
• Really not surprised with the results
  2007-07-25 17:35:18 rickcarson [Reply | View]
  
  

  The solution for your process problems is healthy paranoia. :D

  Let me first define unhealthy paranoia: that everyone else's code is untrustworthy.

  Thus healthy paranoia: that everyone's code is untrustworthy. :D

  The solution in an untrusted situation is to torture your code until it confesses what it is guilty of.

  For other people's code, use exception handling, and lots of it. If you can't trust anything, then exception handling is your friend. If someone tells you that a bug has been fixed, don't believe them until you've run that code yourself and verified it with your own eyes.

  The file system, network and databse really are out to get you. ;-)

  Oh, and move as much of the coding out of XML and into Java as possible, since someone else will bork up the XML, which will fail silently until you go to prod, wherein it will go rambo on the rest of your app.

  Lastly, the solution for waterfall is more paranoia. :D In this case, what you need to do is a bit of upfront design, specifically thinking about how to deal with the sorts of changes that you are likely to get tossed at you. Changes to the business rules, data format, that kind of thing. Particularly cute is when your design needs to support two conflicting requirements. In this scenario the keyword static is not your friend. Since the fastest way to route around this kind of goalpost moving collateral damage is usually to slap down a subclass.

• Really not surprised with the results
  2007-07-22 17:37:00 rickcarson [Reply | View]
  
  

  Although I voted that my home process was better than the work process, I can think of several reasons why a work process could be better.

  First up is the target audience. At home we might just be developing for ourselves, and so have a lot more bumps and warts than would be acceptable in business software.

  Secondly we might be lacking or not bother with some of the apparatus, such as a CVS. If the code isn't being shared, then why have a bunch of sharing tools or regular backups etc.

  Thirdly there may be entire categories of support that we don't get at home. Such as having a testing team or a team responsible solely for deployment.

  Fourthly our time at home is likely unmanaged, whereas at work it is theoretically possible that we could have a really good manager