p=['sh','-c','ls -l | sort'].execute()
println p.text
def f = gsh.find('.', '-name', '*.java', '-ls');
f.pipeTo(lines);
Who doesn’t? Only those who are lucky enough to work on small dedicated teams.
I think it would be an interesting article to face the fact that crap code and low-level developers are a staple of corporate development. The leaders in our industry whine about this a lot but it is a fact of life and it won’t improve due to economic forces. As long as a corporation can pick up a six-pack of developers from Walmart that will work for 50% of what a talented and experienced developer would work for there will be crap code. It doesn’t matter that statistics show the project will take 10x as long or that maintenance costs will be through the roof. I’ve yet to meet a corporation where those concerns matter to anybody above IT manager (if that). Long term maintenance is usually not a planning concern and is part of some other department's budget anyway.
A sad truth is that the majority of crap code performs similar to quality code so many times it is hard to argue for a decent refactoring. I’d be interested in figuring out how to use existing frameworks to better localize the crap code to small crap islands (crapplets?). Early n-tier development did this by letting the so-called junior developers do the 5000-line-per-JSP programming while the experienced developers worked on the server. This was great until people started expecting more usable web interfaces. Now the UI might have as much JavaScript and AJAX magic as the business side of the application.
I have yet to see a software process or framework that tackles this issue realistically. They have “roles” but they don’t specify degrees of capability. When 80% of your team thinks threading concerns are when your clothes start to wear out how do you best place them within a project?
I think it would be fascinating to see a software framework that specifically breaks apart concerns so that you can use your A, B, C, and D developers to the best of their abilities while minimizing the impact of the crap code that the less capable will crank out.
I don’t want to hear any feedback about how you should just get rid of the junior programmers. They have families, they have to eat, and realistically, if downsized, the more expensive developers will get the boot first. Our industry has to figure out how to best utilize the majority of its C and D-level developers. We can’t make them all project-managers.
But then I started to notice something about the Java projects I was involved in: weak teams and weak programmers will go to great lengths to do the wrong thing
Glenn Vanderburg
No Fluff Just Stuff - 2006 Anthology
Buried Treasure Chapter
Has the pragmatic press put out a bad book yet?
I like this quote. It reflects a lot of my experience with teams lately. I’d put a different twist on it.
Here the author was talking about if the “weakest programmers” on the team could be trusted with more powerful language features. An argument may go along the lines of “we need static typing to protect developers from themselves…”.
A trend I’ve seen in large corporate development is to invest more in smart tools than smart developers. The problem is that smart tools keep developers dumb.
I’ve been on teams with very green developers and have had two experiences:
The first is that we set up an ant build that has simple targets. Basically, made it easy for the developer to use whatever IDE they wanted. I just gave them the golden rule that the ant build was king. I also set it up so that server processes kicked off in a console window. Taught them how to use the unix “tail” command on the network servers.
It turned out that even the weakest developers felt very comfortable with this setup. If something didn’t build they could figure out quickly if it was a code issue, a missing library, or something else. I saw them grow very comfortable with the command line and with Java development in general. In short trusting the developers made them smarter and made the team stronger. I’d see signs of this when the developers would be able to solve complicated problems independently. Because they felt close to the metal they felt comfortable trying to dig out and solve issues themselves. Try a little AOP? Sure.
The funny thing is that the code was also better. Smaller classes, less code doing more, better javadoc. Pretty much everything that would make a team leader proud.
The second experience I’ve had is with a company that felt that tools were the solution. Builds, deploys, servers, were all launched from within an IDE. A right-click generated a web-service, or EJB, or JavaBean. Separate teams were responsible for configuration and deployment and each had their own tools. One example was a tool that would try to inspect the .project file from an Eclipse project setup and use that to generate a build script to be used only by the deployment team. Want to take a guess at how much productivity that sucked away? Here is a hint: The solution was to have the development team check in all generated artifacts so the deploy team’s tool would be easier to use.
The tools were smart but kept the developers from knowing what was going on behind the scenes. These developers would be able to crank out 100’s of lines of code but would stumble at the basics. They’d be asking why their workstation has red flags while mine didn’t. They’d be lost as to why a deploy didn’t work. Javadoc would be limited to the crap the IDE spewed out. 100s of TODO statements littered the production code.
In short, smart tools made for dumb programmers.
Why is this? One theory I have is that programmers want to program - not draw pictures or use someone else’s software. If we wanted fancy tools we would be word processors, graphic artists, CAD professionals, etc.
If fancy tools were the solution to good software development then industry would have solved the issue long ago. Yes, I love my IDEs. I love code completion when I can get it. Even debuggers, which I feel is the ultimate “smart tool that keeps programmers dumb” come in useful. I’m just saying that the focus should be on what the developers feel would make them most productive.
It is rare to find the developer who does not have potential. Most want to do the best job they can. Most want to learn new things and be considered competent by the team. At the same time, a company that treats its developers like a disposable and replaceable commodity will get developers who live up to that perception. The U.S. military can take 18-year-olds and train them to use million dollar equipment with confidence. That institution knows that setting the bar high will create a team that works well together and as individuals.
As always The Simposon’s has a relevant episode. In this one Lisa lives down to her expectations when she thinks she has a Simpson-gene that dooms her to slowly become an idiot.
O.K. I’ve been working with Rails for several weeks now and am loving the ease for cranking out websites. Good stuff.
(and that’s a big butt)
For some insane reason the developers of Rails decided plural table names was a convention worth promoting by having it as the default.
Most experienced DBAs will tell you that the name of a table should describe what one record in that table would represent. Who would recommend plural table names? Developers seem to like plural names because they equate database tables with Collections (think java.util.List). I guess I come from a more traditional background where I think of tables as set theory.
Naming guidelines aside there is another reason not to go down this route. Rails then has to be smart enough to parse the plurals for almost every noun in the English dictionary.
What short-circuited in the developer’s brains? They develop this slick environment and then slap in some hacky idea. I think it is only useful to add to the perceived “wow” factor that the Rails enthusiasts get at conferences. yee-ha!
Luckily there is a work-around to make Rails work just as nicely with singular table names.
Thanks to this post on justinram.wordpress.com for providing the answer on how to switch off this really stupid bug in rails:
Add the following to the bottom of your config/environment.rb file:
# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false
Final thing that “really grinds my gears” (Family Guy) is that it goes against the grain of “design by convention” that is Rails major contribution to the web space. Why would all my controllers, views, helpers, etc be called Employee and my table name be Employees?
Why would my code refer to “Sheep” and my table name be “Sheep”. Well, maybe that wasn’t a good example.
I guess in the end there is a difference between convention magic: “Hey, all my MVC objects are named the same so I don’t have to configure them - that makes sense” and spooky “under the covers” magic “Hey I magically figured out that your Alumnus class should be related to the Alumni table”
It is a good thing that Rails has that call to the Dictionary.com web service to get the plural name for every model.