10 reasons to switch from CruiseControl to Hudson

Ten things no one ever told you about Hudson:

  1. It’s extremely easy to install (unzip the file and that’s it)
  2. It can be configured entirely from its friendly Web UI (no XML required)
  3. It has an attractive dashboard with colourful and meaningful icons
  4. It’s extremely flexible
  5. It can be extended via plug-ins
  6. It offers a much better UI than CruiseControl
  7. It can execute Phing, Ant, Gant, NAnt and Maven build scripts
  8. It gives you clean readable URLs for most of its pages
  9. It has RSS, e-mail and IM integration
  10. It can distribute build/test loads to multiple computers

This tutorial guides you step-by-step through the fundamental concepts of Continuous Integration and Hudson. When you are done with this one-hour tutorial, you will understand the benefits of Continuous Integration as well as how to set up your environment.

Links

Four Great InfoQ Presentations

Hope you like these recommendations and if you know of any other good tech-related video, then please let me know.

1. Developing Expertise: Herding Racehorses, Racing Sheep

One of my favourites. In this presentation Dave Thomas (The Pragmatic Programmer) talks about expanding people’s expertise in their domains of interest by not treating them uniformly as they had the same amount of knowledge and level of experience.

Developing Expertise

2. Real World Web Services

Another good presentation. In this one Scott Davis provides a pragmatic, down-to-earth introduction to Web services as used in the real world by public sites, including SOAP-based and REST examples.

Real World Web Services

3. CouchDB and me

This presentation is different, and that’s why I like it so much. Damien Katz shares his experiences and reminds people how difficult but at the same time gratifying is to be an open source developer. He talks about the history of CouchDB development from a very personal point of view. His inspirations for CouchDB and why he decided to move my wife and kids to a cheaper place and live off savings to build this thing.

CouchDB and me

4. Yahoo! Communities Architectures

In this presentation, Ian Flint tries to explain the infrastructure and architecture employed by Yahoo! to keep going a multitude of servers running of different platforms and offering different services. Very interesting!

Yahoo! Communities Architectures

The Importance of Branching Models

Among the branching models used in software configuration management, the branch-by-purpose model offers better support for parallel development efforts and improved control of both planned and emergency software releases. If you want to improve software quality, you must first understand your software. What are its pieces? How are they organized and related to one another? If you do not understand your code base, your odds of updating it without breaking something are poor.

The Importance of Branching Models (PDF)

Links

High-level Best Practices in Software Configuration Management

How to kill an idea, or help it grow

It is far easier to kill an idea than to encourage it and turn it into a useful solution. Be on a constant watchout for putting down an idea too early without understanding the positive reasons for it being suggested. Hopefully you will see that there are many ways in which you can be constructive.

To kill an idea, say:

  • It’s not part of your job
  • That’s not what we do here
  • Costs too much
  • Against the company policy
  • It’s not budgeted, maybe next year
  • Let the other department handle that
  • It is not our problem
  • Why would you do something like that?
  • We have been doing it another way for a long time and it works fine
  • If it’s so good, why hasn’t someone suggested it already?
  • Has anyone else tried it successfully?
  • We have tried that before and it didn’t work
  • Is anyone crazy enough to try that?
  • We’re already doing that

To help an idea, say:

  • Yes, and…
  • Great, let’s try it
  • How can we make time to see if it will work?
  • What resources would we need to do it? Tell me more
  • How can we make it work?
  • What are the advantages?
  • How can we remove the dis-advantages?
  • What can I do to help this happen?
  • I like it
  • That sounds interesting, tell me more
  • How can we convince everyone else?

Leading a Software Development Team

36 steps to success as technical lead

  1. Define early on what success means for you, the team and the business.
  2. Believe in the project: idea, architecture, time, team.
  3. Understand the domain, the business requirements and the technical challenges.
  4. Know your team: strengths, weaknesses, ambitions and personalities.
  5. Have a plan as a result of a planning activity.
  6. Be part in the design of everything.
  7. Get your hands dirty and code.
  8. Act as a communication proxy for your team.
  9. Make sure everybody understands the big picture: their work has implications.
  10. Fight for architecture and design consistency.

Read more

How not to lead geeks

  1. Downplay training.
  2. Give no recognition.
  3. Plan too much overtime.
  4. Use management-speak.
  5. Try to be smarter than the geeks.
  6. Act inconsistently.
  7. Ignore the geeks.
  8. Make decisions without consulting them.
  9. Don’t give them tools.
  10. Forget that geeks are creative workers.

Read more

Nine things developers want more than money

  1. Being set up to succeed.
  2. Having excellent management.
  3. Learning new things.
  4. Exercising creativity and solving the right kind of problems.
  5. Having a voice.
  6. Being recognized for hard work.
  7. Building something that matters.
  8. Building software without an act of congress.
  9. Having few legacy constraints.

Read more

Top 10 ways to demotivate your programming team

  1. Set up impossible deadlines.
  2. Let them work overtime.
  3. Don’t allow breaks.
  4. Place a ban on laughing.
  5. Break the coffee machine.
  6. Don’t shield them from the dirty daily business.
  7. Don’t challenge them.
  8. Underpay them.
  9. Bribe them.
  10. Infiltrate a team member who is demotivated anyway.

Read more

Don’t bring me solutions, bring me problems

(Don’t tell me how you want it to work, tell me what you want it to do)

  1. Where all think alike, no one thinks very much.
  2. Suggesting solutions kills creativity.
  3. Don’t bring me solutions, bring me problems.

Read more

Classic mistakes enumerated

  1. Undermined motivation.
  2. Weak personnel.
  3. Uncontrolled problem employees.
  4. Heroics.
  5. Adding people to a late project.
  6. Noisy, crowded offices.
  7. Friction between developers and customers.
  8. Unrealistic expectations.
  9. Lack of effective project sponsorship.
  10. Lack of stakeholder buy-in.
  11. Lack of user input.
  12. Politics placed over substance.
  13. Wishful thinking.

Read more

Seven practices for healthier, faster software development

The practices discussed in this article are based on Ezequiel Cuellar’s observations. These practices will help any software development team as they come up against common obstacles. They will also contribute to a solid foundation for healthier development and help speed up production. The seven practices are:

  1. Improve business processes before starting development.
  2. Create a solid software development team.
  3. Improve processes for service requests.
  4. Minimize reporting of software metrics.
  5. Improve communication with the business team.
  6. Use the right programming language.
  7. Use the right IDE.

The practices target problems that are better addressed at the management level. Usually, developers can only report the issues to upper management for consideration. Because project managers have the necessary level of authorization, they are the ideal candidates to promote these practices within the organization.

Continue reading