brewing up java stuff pinoy style

do you have to know everything all the time?

2008-02-08T02:04:00Z

i don't know about you guys but i'm starting to get mentally exhausted at the rate technology has been changing in recent years. how many java web frameworks are out there today? 60? 70? 100? and the list keeps on getting LONGER.

here's a bit of soothing salve to remedy that big headache of yours:

Do you ever feel like you're buried under umpteen zillion backlogged emails, feeds, books, articles, journals, magazines, and printouts? Do you ever feel that you're hopelessly behind, with so much new stuff created every day that you can never possibly hope to keep up?

Well, you're not alone.

Via SecretGeek:

You do NOT have to refactor all your code.
You do NOT have to keep up with the latest news from microsoft, and know everythnig there is to know about longhorn, whidbey, avalon, XAML, indigo and star wars III.
You do not have to have perfectly de-coupled tiers in your technology independent SOA software.
You do not have to comply to every standard, achieve the perfect balance between maintainability and performance. Usability and familiarity.
You don't have to do "first things first every day"
You DO NOT have to memorize and understand every patten the gang of four have catalogued.
You do NOT have to read every technical blog, print out every technical article and learn every technical thing there is to learn.
You are beautiful just the way you are.
You are brilliant, interesting, wise and fun to be around.
You rock.

Prefer Broad Design Skills over Platform Knowledge

2008-02-08T01:58:00Z

link: http://www.infoq.com/news/2008/01/prefere-broad-design-skills

Building a team is always a tricky task since it is pretty unlikely to
find people who would fit all the criteria of the ideal candidate.
Trade-offs are inevitable and, in this context, it is crucial to
determine priorities. Broad skills, in terms of software design but
not only, this is what really matters for Martin Fowler.

He asserts in his latest article, that if he had to choose between
someone who knows very well the platform used but has limited
knowledge about design and someone else who has broad design skills
but knows nothing about the specific technology used on the project,
he would choose the latter. He argues, indeed, that even though design
skills are not fully portable from one technology to another and
cannot be replicated blindly, great part of them can carry over not
only among similar technologies but also from curly-brace languages to
Ruby, for example.

the hardest questions to answer when you're a software developer

2007-09-06T12:53:25Z

gaano katagal pa yan?
malapit na ba matapos?

Scorn Globally, Act Locally

2007-08-16T04:30:47Z

in an ideal world, all projects we handle have source code that are so beautifully crafted that merely reading them gives you a sense of enlightenment and makes you marvel at the simplicity of the code (and for a few gives you that warm fuzzy feeling ... ). in reality, well ... *sigh* =)

for those of us who maintain other people's code for a living, here's something to ponder over while you're pulling your hair and pounding on that wall or table in frustration from trying to understand what the hell that other person was thinking when he/she wrote that bit of code you're trying to debug.

Beautiful Code in the Real World - Part II: Scorn Globally, Act Locally
by Alberto Savoia
August 14, 2007

Summary
How to inject beauty in a coyote ugly code base.

In Part I, I mentioned one of the dilemmas voiced by developers who want to inject some beautiful code in their day-to-day activities:

“I am maintaining a steaming pile of legacy code that I have inherited. I can barely keep the code base working – sort of. I would love to write some beautiful code, but have no time to think about beauty as long as I am saddled with this ugly code base.”

This is a very common situation. Most developers spend most of their time maintaining/enhancing code that they did not write and, more often than not, that code base is not just ugly, but coyote ugly.

argh ... deadlock

2007-08-03T02:36:00Z

just when we were starting to feel really good about our chances of delivering a working and performant system, i get an email from the stress test guy of our client saying our transactions are causing table locks left and right.

what the .....

now i don't remember any process that involved locking tables or anything close to that. no one in the team has any knowledge of that either.

whipped out jmeter and started running some long running tests to try to pop the sucker out. the script was simple:

login
create a record
save the record
delete the record
logout

after 3 minutes of continuously running the script, we were able to replicate the bugger.

%#$%, something was locking the tables.

after a lot of frantic google and hibernate forum searching, we come across this:

http://www.archaebacteria.net/?p=21

and got this from my boss:

http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg05495.html

in a nutshell, from lukas barton's blog:

If an index exists on the foreign key column of the child table, no DML locks, other than a lock over the rows being modified, are required.
If the index is not created, a share lock is taken out on the child table for the duration of the transaction.

woopeedoo. created the indices, deployed update @ client, resumed testing ...

... so far so good.

101 Ways To Know Your Software Project Is Doomed

2007-07-19T10:54:36Z

got this from my boss today. my personal favorites: 17, 36, and 100 (best of the lot)

Management has renamed its Waterfall process to Agile Waterfall
You start hiring consultants so they can take the blame
The Continuous Integration server has returned the error message “*** it, I give up”
You have implemented your own Ruby framework that uses XML configuration files
Your eldest team member references Martin Fowler as a ’snot-nosed punk’
Your source code control system is a series of folders on a shared drive
Allocated QA time is for Q and A why your crap is broken
All of your requirements are written on a used cocktail napkin
You start considering a new job so you don’t have to maintain the application you are building
The lead web developer thinks the X in XHTML means ‘extreme’
Ever iteration meeting starts with “Do you want the good news or the bad news…”
Your team still gives a crap about its CMM Level
Progress is now measured by the number of fixed bugs and not completed features
Continuous Integration is getting new employees to read the employee handbook
You are friends with the janitor
The SCRUM master doesn’t really care what you did yesterday or what you will do today
Every milestone ends in a dead sprint
Your best developer only has his A+ Certification
You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR
Your manager could be replaced by an email redirection batch file
The only certification your software process has is ISO 9001/2000
Your manager thinks ‘Metrics’ is a type of protein drink
Every bug is prioritized as Critical
Every feature is prioritized as Trivial
Project estimates magically match the budget
Developers use the excuse of ’self documenting code’ for no comments
Your favorite software pattern is God Object
You still believe compiling is a form of testing
Developers still use Notepad as an IDE
Your manager wastes 7 hours a week asking for progress reports (true story)
You do not have your own machine and you are not doing pair programming
Team Rule - No meetings until 10 AM since we were all here until 2 AM
Your team believes ORM is a ‘fad’
Your team believes the transition from VB6 to VB.NET will be ’seamless’
Your manager thinks MS Project is the best management tool the market offers
Your spouse only gets to see you on a webcam
None of your unit tests have asserts in them
FrontPage is your web page editor of choice
You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC
The company motto is ‘Do more with less’
The phrase ‘It works on my machine’ is heard more than once a day
The last conference your .NET team attended was Apple WWDC 2000
Your manager insists that you track all activity but never uses the information to make decisions
All debugging occurs on the live server
Your manager does not know how to check email
Your manager thinks being SOX compliant means not working on baseball nights
The company hires Senetor Ted Stevens to give your project kick-off inspiration speech
The last book you read - Visual InterDev 6 Bible
The overall budget is mistaken for your weekly Mountain Dew bill
Your manager spends his lunch hour crying in his car (another true story)
Your lead web developer defines AJAX as a cleaning product
Your boss expects you to spend the next 2 days creating a purchase request for a $50 component
The sales team decreased your estimates because they believe you can work faster
Requirement - Rank #1 on Google
Everyday you work until Midnight, everyday your boss leaves at 4:30
Your manager loves to say “Why do the developers care? They get paid by the hour.”
The night shift at Starbucks knows you by name
Management can not understand why anyone needs more than a single monitor
Your development team only uses source control as a power failure backup system
Developers are not responsible for any testing
The team does not use SVN because they believe the merge algorithms are black voodoo magic
Your white boards are mostly white (VersionOne)
The client continually mistakes your burn-down chart for a burn-up chart
The project code name is renamed to ‘The Death March’
Now it physically pains you to say the word - Yes
Your teammates don’t refactor, they refuctor
To reward you for all of your overtime your boss purchases a new coffee maker
Your project budget is entered in the company ledger as ‘Corporate Overhead’
You secretly outsource pieces of the project so you can blog at work
A Change Control Board is created and your product isn’t even its first alpha version
Daily you consider breaking your fingers for the short term disability check
The deadline has been renamed a ‘milestone’…just like the last ‘milestone’
Your project managers ‘open door’ policy only applies between 5:01 PM - 7:59 AM
Your boss argues “Why buy it when we can built it!”
You bring beer to the office during your 2nd shift
The project manager is spotted consulting a Ouija board
You give misinformation to your teammates so you look better on your personal review
All code reviews are scheduled a week before product launch
Budget for testing exists as “if we have time”
The client will only talk about the requirements after they receive a fixed estimation
The boss does not find the humor in Dilbert
You start noticing your boss’s poker tells during planning poker
You start wondering if working 2 shifts at Pizza Hut is a better career alternative
All performance issues are resolved by getting larger machines
The project has been demoted to being released as a permanent ‘Beta’ version
Your car is towed from the office parking lot as it was thought to be abandoned
The project manager likes to doodle during requirements gathering meetings
Your SCRUM team consists of 1
Your timesheet looks like a Powerball ticket
The web developer thinks being 508 means looking good in her Levi Red Tabs
You think you need Multiple Personality Disorder medication because you are Mort, Elvis, and Einstein
Your manager substitutes professional consultant advice for a Magic 8 Ball
You know exactly how many compile warnings cause an ‘Out of Memory’ exception in your IDE
I have used IDE twice in this list and you still don’t know what it stands for
You have cut and pasted code from The Daily WTF
Broken unit tests are deleted because they are obviously out of date
You are sent to a conference to learn, but you skip sessions to go hunting for swag
QA has nicknamed you Chief Off-By-One
You are using MOSS 2007
You have been 90% complete 90% of the time
“Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too… thanks”

the real deal transformer

2007-07-18T06:50:00Z

coming soon to a store near you

CLICK ME

Teach Yourself Programming in Ten Years

2007-07-17T09:34:57Z

link: http://www.norvig.com/21-days.html

as one of my former PE teachers used to say, "good practice makes good perfect"

Teach Yourself Programming in Ten Years

by Peter Norvig

Why is everyone in such a rush?

Walk into any bookstore, and you'll see how to Teach Yourself Java in 7 Days alongside endless variations offering to teach Visual Basic, Windows, the Internet, and so on in a few days or hours. I did the following power search at Amazon.com:

     pubdate: after 1992 and title: days and
      (title: learn or title: teach yourself)

and got back 248 hits. The first 78 were computer books (number 79 was Learn Bengali in 30 days). I replaced "days" with "hours" and got remarkably similar results: 253 more books, with 77 computer books followed by Teach Yourself Grammar and Style in 24 Hours at number 78. Out of the top 200 total, 96% were computer books.

The conclusion is that either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days.

Let's analyze what a title like Learn Pascal in Three Days could mean:

Learn: In 3 days you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in that environment. In short, you won't have time to learn much. So they can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.
Pascal: In 3 days you might be able to learn the syntax of Pascal (if you already knew a similar language), but you couldn't learn much about how to use the syntax. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using Pascal syntax, but you couldn't learn what Pascal is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of Pascal (or more likely, something like Visual Basic or JavaScript) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
in Three Days: Unfortunately, this is not enough, as the next section shows.

Teach Yourself Programming in Ten Years

Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson thought it took longer than ten years: "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer complained "the lyf so short, the craft so long to lerne."

Here's my recipe for programming success:

Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
Talk to other programmers; read other programs. This is more important than any book or training course.
Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).
Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.
Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).
Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)
Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.
Have the good sense to get off the language standardization effort as quickly as possible.

With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.

Fred Brooks, in his essay No Silver Bullets identified a three-part plan for finding great software designers:

Systematically identify top designers as early as possible.
Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.
Provide opportunities for growing designers to interact and stimulate each other.

This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers".

So go ahead and buy that Java book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours, days, or even months.

The seven sins of programmers

2007-07-12T10:43:43Z

By Steve Goodwin

link: http://www.freesoftwaremagazine.com/articles/the_seven_sins_of_programmers

Online on: 2007-04-11

Programmers. The system administrators worship their bit twiddling capabilities. The users exchange vast quantities of beer for new features and tools. And the project managers sell their souls when they make the magic work. But inside the average programmer’s psyche are several demons that need exorcising.

Pride

This is all too common in programmers. Instead of asking whether a particular function exists, or for the best way to retrieve data from the system, a proud programmer is likely to write their own. Especially when faced with a large, or unfamiliar, code base. By re-inventing the wheel there are now two very similar routines. Not only does this increase the code size, it doubles the amount of maintenance required, creates another opportunity for bugs, and adds inconsistency. Later, when another programmer sees these two functions, they will have to choose between them. Which one will depend on their mood (are they also too proud to seek help?), who’s on holiday or who’s outside smoking, at the time! This can equally be applied to duplicate constants, member variables or structures.

Code reviews... must focus on the code, not the coder

Code reviews with a senior team member can help quell a developer’s pride, and guide the other developers in the appropriate direction. This is basic employee training, and one that is simple to implement. Reviews also force the developer to reason each decision made, and justify the creation of new utility routines, perhaps explaining to the lead why existing standard code was not used. To be constructive the review must focus on the code, not the coder, and support free flowing ideas, regardless of the relative seniority of the reviewers. Remember that if the developer is too proud they’ll be closed to ideas, or won’t suggest improvements.

Envy

Programmers should improve themselves by learning from others, not blindly emulating them. All coding methodologies (be they syntactical or design-based) come with caveats. A programmer might inline a function with the pre-processor because he’s seen it done elsewhere, unaware of potential side effects, as in this classic example.

#define SQUARE(x)	x*x

Similar evils occur when programmers move between languages. An experienced developer will typically have a specific style that he tries to crowbar into every other language. Perl written like C. Java written like Ruby. We’ve all seen the examples. Naturally, you should use the best tool for the job, and work to the strengths of that language. By trying to fit idioms from one language into another highlights the fact you understand neither. It’s a development fact of life that some languages are better suited to some tasks, so adapt to it, and close those envious eyes that look at the language you’d rather use. Remember the oft-quoted saying, “When all you have is a hammer, everything looks like a nail”.

Gluttony

Not an evening at the all-you-can-eat buffet, but the problem of writing too much code. Every hour spent coding will require an extra hour of testing, and possibly two more of maintenance. And guess who gets lumbered with the maintenance?

Worse still, this does not scale. A two-minute feature (or one line bug fix) may also take an hour to test. Whatever your gluttonous reasons are—attempts to impress, an under-staffed team, late night camaraderie, or personal pride—curb them. Spending the whole morning trying to unravel last nights two-minute feature is like the buffet—you get stuffed afterwards!

Lust

Programmers crave pleasure; they love to “scratch their own itches”. If unchecked, some developers will write fantastic, innovative, original... and completely unnecessary, code. It could be a new graphics shader, a faster search algorithm or an entire processing engine! If you’re working on anything other than a pet project, you will probably have a schedule that must be adhered to, and a set of pre-determined priorities. These affect the whole project, and not just the wanton lust of an individual developer. Unless you are called Spock, the needs of the many, outweigh the needs of the few... or the one.

Make sure any code written is actually needed. Will it get used? Or will it distract the users who, in turn, add a new plug-in system, just to make use of the code? One very common example of this is premature optimization. Without profiling the code it is impossible to tell exactly where the bottlenecks will occur. Granted, most developers can look at a function and give several reasons why it is slower than it could be, but very few can tell you want percentage of the total running time that function will occupy. Unless it’s known to be on the critical path, then it’s probably not worth optimizing at this time.

The desire to write new code can also exclude the possibility of introducing middleware as a viable solution. The cliché chant is then of “Not Invented Here”. Programmer X once said,

“I’m not using middleware since I don’t understand it; it’ll be just as quick to write it myself. How can I be expected to maintain something I don’t understand?”

He was erroneous for many reasons. Firstly, the initial period of evaluation would give him experience with the code base, and should be a pre-requisite when introducing any new code to a project. Secondly, he’s only considered the development time in terms of coding, when in actuality much of it is taken up with testing—something any sensible middleware product would have in abundance—and as we’ve already seen, writing code doesn’t scale to the subsequent testing and maintenance phases. And finally, there are other trade-offs between write and buy, such as access to other developer forums, paid consultancy, and third party contracts which determine whether the purchase of middleware is a good idea for your specific project.

Curbing programmer lust in this way allows more time spent on the important tasks. This would include writing original, novel, parts of the software and learning the middleware solution itself. After all, it is usually quicker to read, than to write.

Anger

Do not code out of anger. Do not ignore good ideas, regardless from where they come. If a more junior programmer has a solution to the problem in hand—discuss it. If it works—use it! The engine programmer should not be allowed to implement his own solution just because “He’s the engine programmer”.

Anger leads to hate. Hate leads to suffering. To bad code does that lead

Do not code out of spite. Lead programmers: love your coders. Code reviews, for example, should raise the ability of the whole team, and not be used for leads to show off, introduce new jargon, demonstrate obfuscated syntax or exhibit other prima donna characteristics.

Do not code out of fury. Programmers: love your leads. They distribute work because it needs doing. Don’t work on somebody else’s tasks because you’re more suited, or believe it should have been yours. If you want to move into other areas of programming, talk to your lead. Develop prototypes at home. Employing enthusiasm in this manner will win more brownie points than ignoring the task list and schedule.

Sloth

Don’t procrastinate! If a particular piece of code is uninteresting or difficult (like an obscure crash bug), more interesting tasks should be available to compensate. Look forward to those tasks, but don’t daydream about them. If you stop every five minutes for a coffee and chat (or more likely, a whinge) then the task will take much longer, and it will become a self-fulfilling prophecy. Instead, begin with a cup of coffee, a bag of sweets, and your favorite MP3s. Then lose yourself and knuckle down to the task in hand. It won’t be as bad as you think as even dull work makes time pass quickly if you become engrossed in it.

Also, make sure all the tasks are clear, consistent and given from one manager. Opposing requests from different managers will make one of them unhappy, and starting such a doomed task is no fun for anybody.

Greed

There are a couple of places where developers suffer greed. We have already touched on one, and this is a programmer’s innate desire to do too much. The proverbial “biting off more than you can chew” scenario leads to an exponential increase in testing, and a swell of code paths to verify. It can also lead to a lower quality of code since the problem domain may not be well understood by the developer assigned, and the increased workload limits their opportunity to learn.

The final greedy point is directed more towards management, as everyone should feel valued—financially and metaphorically. This is especially true during crunch-time, when even the most junior programmer can work out that their hourly pay packet could be improved by working on the cold meat counter at Tesco! Paying for late night food goes without saying (I hope!), but an occasional pub evening also helps. This gets everyone out the office, and shows that management aren’t greedy with an employee’s time, either. Many ambitious people, regardless of salary, always want more. So even the lead programmer will start questioning their role and think “I’m worth more than this” when they feel unappreciated. How many times do you hear “I’m so overpaid”, compared to “I’m so underpaid”?

Leads should check for warning signs, like “funny” comments in the code—“I’ll do this properly when I get a fscking pay rise!!!”. Management should be wary of stopping or limiting low-cost company perks (such as free soda) since the loss in productivity and willingness to do overtime is undoubtedly greater than the few dollars spent. Follow Dilbert. Less money for staff does not mean more for management.

Naturally, the lead programmer should help prevent such sinful practices. But as responsible professionals, we should all try and curb the devil inside first. Of course, not everyone is Beelzebub incarnate, so score yourself honestly out of ten for each category, and ask a colleague to do the same for you. Then compare. I score 4, 2, 6, 1, 1, 2 and 3 on the categories above, but pride prevents me from letting you in on which scores are for which categories...

everybody loves the paperclip

2007-04-13T12:02:00Z

project muni-muni

2007-03-30T02:12:00Z

we delivered the software with an hour to spare. software development projects just aren't as fun and exciting if you don't let murphy impose his law upon it.

it has been said hundreds of times before, and yes i will say it again: PEOPLE, NOT TOOLS, MAKE GOOD SOFTWARE. and for this project i have been blessed with a great team, one with people with the right attitude, work ethics, and dedication to quality.

i'm not saying that tools aren't necessary. on the contrary, having the right tools can and will make your life easier. it just saddens me that some companies would rather invest in tools (or in all that cmm certification crap) than in their people, and this mentality seems to abound in our country.

on my way home last night i went over the right decisions that were made (by me or my company) during the course of the project that helped us deliver what was required. here are some of those:

1. we used appfuse

yes, hibernate was great. yes, spring was a big help. yes, displaytag saved us a lot of time. yes xfire kicks ass. but at the end of the day, if you can't bind them all seamlessly together then you may have a lot of work in your hands in the future. appfuse just takes all of these integration concerns out of your hands and lets you focus more on the business requirements. after all, at the end of the day the client isn't at all concerned if you used the latest and greatest version of ABC framework or XYZ library. what they want to see is a product that does what they said it should do.

you may have the best technologies in your project, but if you can't deliver what is expected then you don't have much.

making a new module? no problem. make your domain objects, put the necessary xdoclet tags (we weren't using the latest version of appfuse so annotations weren't supported yet), run the code generator, and you're done. DAOs, configuration files, database tables, and all the other necessary classes are automagically created for you. tweak it a bit to suit your taste and you have the baseline of your module.

2. we used jira

jira, by leaps and bounds, is the best issue tracking system i have used ... EVER. bugs are a fact of life in software development, and managing these can make or break a project if you let them run amuck.

jira makes tracking all of these extremely easy, and creating tickets would take just a couple of seconds of your time. found a bug? then make an entry! i've experienced using a crappy bug tracking system that took almost 2 minutes to create a record, and in the end i ended up just using a spreadsheet or verbally telling someone that something was wrong. tools are supposed to make your life easier, not make it more complicated.

3. we used luntbuild

continuous integration is essential in any software development endeavor. i've used cruisecontrol in the past and it did the job. it was, however, a pain to configure. luntbuild lets you configure everything from a web interface within a couple of minutes.

i've read that hudson is even simpler to use. haven't used it but am extremely interested in giving it a test drive.

off the top of my head those were the essential things that went well. there are probably some more but i'm too lazy to list all of them down. maybe i'll mention some of them in future posts.