Entries Tagged 'Software Engineering' ↓

Writing User Stories the Easy Way

Max Pool over at codesqueeze has a great article on how to write a good user story. I’ve seen developers equate a user story with a software requirement before without realizing the subtle differences between the two (mainly that a user story is short and focused on something that the user needs to do). By using Max’s template, you can ensure that you keep your stories short and focused on solving a user task.

*****

Tips on Iterative Development

John Reynolds has some tips on Iterative Development on his blog. He goes into what exactly iterative development is and points out how it differs from incremental development. It is easy (especially for managers) to get the two confused and fall into the incremental development trap. Good read and something you may want to forward on to your team lead or boss.

*****

UI-First Development

Jeff Atwood has an excellent post on the importance of UI-Driven Development. If you haven’t heard of this before, this is a good article to check out. It has plenty of links to supporting arguments and explanations about why you should develop the user interface of your application first.

*****

Comfort vs Confidence

Max Pool at CodeSqueeze has an interesting article on the decision between comfort and confidence. The article talks about how most teams will develop software not using the best tools for the job, but rather the tools they are comfortable with. It ends with some sage advice, telling you to get outside of your comfort zone occasionally and learn something new (say, maybe, a new programming language?).

*****

Scott Bain on Writing Maintainable Code

RegDeveloper has the first in a five-part series from Scott Bain’s new book “Emergent Design: The Evolutionary Nature of Professional Software Development” up on their site today. In it, Scott goes over some basic qualities found in well-written maintainable code. I’ll be looking forward to reading the rest of the excerpts and eventually the book.

*****

It’s your fault!

Jeff Atwood at Coding Horror has an excellent article this morning entitled “The First Rule of Programming: It’s Always Your Fault“. This is particularly hilarious to me since I have seen this in action many times… Hibernate seems to be a recurring target of this anti-pattern. I’ve seen engineers on multiple occasions swear that something is wrong with Hibernate or that there is a bug in Hibernate and then propose to rip out the persistence layer all together and replace it with some home-grown JDBC interface. Tempers flare for a day or so and then finally somebody reads the docs and figures out the quirk in our code that caused the problems.  Mr. Atwood is doling out sound advice here and this is a good article to keep on hand for the next time you hear one of your peers suggest writing your own, less buggy, persistence layer.

*****

Six Ways to Write More Comprehensible Code

Jeff Vogel has an article on IBM’s developerWorks giving six tips to writing more comprehensible code. The examples given are in C++, but the tips are equally applicable to programming in any language.

*****

Ten ways to improve your code

RegDeveloper has a summarization of Neal Ford’s 10 Ways to Improve Your Code talk at SD West 2008 up on their site. All of these are good practices and things we, as software developers, should strive to do at work every day.

*****

The Savvy Duck on Refactoring

Andy at the Savvy Duck has an interesting post this morning on Refactoring. The emphasis of his article isn’t so much on techniques of refactoring, but on the human relationship side of things (refactoring other people’s code for example) and how communication is key. This is a good article that discusses things that aren’t often talked about in refactoring books or computer science courses, but comes up all of the time in the real world.

*****

Reality Driven Development

Gustavo Duarte writes today about Reality Driven Development. This is meant to be a further explanation of a post of his that got Slashdotted last week. It’s a good read that advocates experimenting during the software process and getting feedback (from reality/the user) often.

*****