Entries Tagged 'Software Engineering' ↓

Gojko Adzic has a list of Test Driven Development anti-patterns on his blog. Unfortunately, I’ve seen many of these crimes practiced in real life and can say that they generally always come back to bite you. The list includes activities such as commenting out a test to make the build pass, sensitivity to the UI, and sensitivity to 3rd party APIs.

Six Revisions has Eight Tips on How to Manage Feature Creep. IMHO, the most important tip is to  just plain accept the fact that feature creep is going to happen, and work some time into the schedule for it. Flat out rejecting all of the customers requests after the requirements document has been drawn up is a sure-fire way to loose a customer. It is much better to put a fudge-factor into your delivery estimates so that when things come up, you know you’ll have some time to handle them.

James Golick has an interesting post on his blog entitled “The Crunch Mode Paradox“. The basic premise is that during crunch time, even though your developers are putting in more hours, productivity decreases and the chance of introducing bugs increases dramatically. Any developer who has had to pull a few all nighters before a release date knows that the code written in those wee hours of the night isn’t exactly the cleanest.

This is one you’ll want to send to your manager!

The title says it all. DevTopics has a list of the twenty most famous software disasters.

I have two posts for you today on the recruitment of Software Engineers. The first one was actually posted yesterday over at Coding Horror. Jeff Atwood talks about the “years of experience” myth and how requiring a developer to have X number of years doing Y is outright ridiculous. I think Jeff sums it up best by saying that “what software developers do best is learn” and that in the long run, the developer who is a great programmer but may have no experience doing a specific task will outperform the mediocre programmer with X number years of experience doing the same task.

Along those same lines, Martin Fowler posted a hypothesis today answering the question “Are more expensive programmers actually cheaper?“. He suggests that a group of more expensive (more talented) programmers can get a better system completed earlier than a group of cheap talent, and that the initial savings gained by hiring the cheaper talent is expended later in the cycle.

A group of students at the Hasso-Plattner-Institut (HPI) in Potsdam, Germany came up with a novel way of communicating their project status. They hooked up a homemade stop-light system, dubbed “The Golight” to their continuous integration system that switches the lights on and off based on whether or not their unit tests passed. 

TheCodist.com has a good post today about the trials of multithreaded programming in Java, likening it to juggling chainsaws: “amazing when it works and truly sucky when it doesn’t”.

There is an interesting post on the Agile Ajax blog at Pathfinder regarding Software Architects on small development teams. Personally, I’m uncomfortable with the position because it implies that there is one or two “architects” on a team and everybody else is doing the grunt work.

Jason McDonald posted some quick reference diagrams for the Gang of Four design patterns on his site today. Each section has the name of the pattern, a quick description, and the class diagram for the pattern. Definitely a handy thing to have around.

Too often, the usability of an application is either an after-thought or not considered at all. Smashing Magazine has a list of 10 recommended usability and interface design books. If you’re involved in the coding or design of user interfaces (web-based applications included), I would highly recommend picking up one or more of these.