Years ago I had an employee, let's call him Vanya (not the real name). He was struggling a bit so I was watching his work closely. Every week we discussed what he needed to get done the next week and what he had done the previous week. I kept a list of the work items he needed to complete and checked them off when he was done with each. For one particular work item which was testing a particular DirectShow filter, the item on the list was writing tests for it. One week he worked on and completed this work. A few months later we became aware of an issue that would fundamentally cause the filter to not work. In fact, it had probably never worked.

Coupling is the AIDS of software development. It won’t directly kill your project but it will make it easy for something else to kill it off. As coupling rises the ability of the developers to simply understand the code, make orthogonal changes, and test the thing is reduced. You can measure these symptoms as the length of time it takes to make a change, add a new feature, or fix a defect. Eventually these problems get so bad that the “One Rewrite To Rule Them All” is ordered from CEO-ron from up on corporate Mount Doom or the whole thing is simply cancelled. Both of those are generally thought of as Bad Things.

For those living under a rock, GridGain is a Java implementation of a Google-ish map / reduce system. The effect is that, with very little code and even less configuration, one can cause suitable code to run in parallel, on a grid of JVM nodes.

Behavior-driven development offers many of the benefits of test-driven development, but without the tight coupling to specific implementations. In this article Rod Coffin discusses the difference between the two development methods and explains the concepts of BDD. He then walks through an example in behavior-driven development with easyb -- a Groovy-based framework that employs a rich DSL understandable by both developers and domain experts.

Developing web applications is getting more complex - it’s easy to accidentally break functionality as changes are made. In this article, Ben describes the setup his team uses to test their apps as changes are committed; automatically notifying the developers of any problems.

Reflections on spending one day doing TDD. Then other thoughts about how testing has changed my developer habits.

Writing unit-tests should be part of your development process whether you write them before or after the actual coding I leave that up to you. On of the pitfalls of writing unit tests is that the units become to big. The unit your are testing, a method in most cases probably uses some other beans or services to do its job. In your unit test you don’t want to test those other beans but just your method.

Like many design patterns, the abstract factory pattern and the builder pattern appear very similar in terms of their class structure. They are both creational patterns used to construct complex object families. However, the builder pattern has an emphasis on step-by-step construction of each part of the composite structure, whereas the abstract factory is designed to return a constructed object immediately.

An inspiring story about a vegetable vendor, explaining programming and experiencing how programming doesn't come naturally... As the college season is in full flow, I'm back to my philosophical self and I've something for my students... Last week, I was conducting the regular Assembly Programming practicals, where I'm supposed to teach students 8085/8086/8051 ASM programming.

In object oriented design (OO), we give clear responsibility to each object. Object is like a black box which can receives and sends messages. All the objects together form the complete system. Design patterns by gang of four introduced many general reusable solutions to a commonly occurring problems in software design. I always use to correlate interactions between objects to real life interactions involving people and or real things. If you look around, you can see many real life examples for patterns but played out with people instead of real objects. In this article, I will try to explain few of these real life examples of design patterns to you.

A common source of confusion for new software testers is the difference between unit testing and module testing. In general, unit tests are a collection of tests written by a developer during the software development process. Module tests are a collection of tests written by a tester after some code has been written by a developer. There are many exceptions to this generalization but the key point is that unit testing is primarily a development related activity, and module testing is primarily a testing related activity. When a developer creates unit tests during development, this approach is sometimes called test driven development. So which is better, unit testing or module testing? The answer is that the two approaches are complementary, not exclusive.

Do you work in a group or a team? If you can see your work environment objectively you will know whether your colleagues are eager to work and solve technical problems in your project or rather they are told what to do by the manager. If you are told what to do i.e. your team lead decides what you should work on next (or even tell you how to work) you work in a group.

The numbers on success vary widely depending on what factors are considered to define success. Was the project within budget? Were the stakeholders satisfied? Did the project complete on time? Oddly, the one criterion not found was user satisfaction. Does this mean that if it was within budget, on time, and stakeholders (rarely users) were satisfied, but no one used the software, it was still a success?

Some people think that agile and budgeting are incompatible. The product is ready when the product owner says it is. But before starting a project, most managers want at a least budget. So the product owner puts together his wish list and asks the ScrumMaster what it will cost to build. The answer comes back – usually a long time and whole lot of money! Then the customer turns pale as he tries to decide what it will really cost, whether he can afford it and whether it’s worth it. But there is a better way: the product owner can perform a double worst case analysis. This quick and easy tool uses the project’s business value to determine a reasonable price for the software investment.

Suppose we are building yet-another-order-basket-application. We have the requirement for adding items to an order, otherwise the business of our entire company falls down and we are losing tons of money (while not overdramatizing things).

Agile methods don't address project status reporting...

This is the first in a series of posts on what I've learned about how we're doing (and not doing, as I've learned) Scrum on a big project at my work. Hopefully our story will help other teams on their road to becoming Agile. We were brought Scrum by the vendor of the new billing system we were integrating. We all liked the iterations, taking on tasks, demos, etc. Except the day-long planning meetings

Many studies on agile practices are classroom and student oriented, which may not easily translate into a corporate environment with experienced developers. This study surveys programmers who have used an agile process on real projects in Microsoft.

Product Manager (PM) is supposed to represent the voice of the customer, Product Owner (PO) is supposed to be the single wringable neck of a project, the one who prioritizes requirements for the team from the point of view of the customer. In my opinion these roles are overlapping and in many organizations can be equal. However, in general there is a minor, but important difference.

If you have missed on some top articles of Visual Studio Team System (VSTS) and Team Foundation Server (TFS) on dotnetcurry.com, then this is a must read for you. The Top 10 articles have been decided by our editorial panel based on the popularity of the article, user rating and top views of the articles.

Maybe these are old news for a lot of people in the community, but I just found these three great lectures about Python over at google code university

.net has really taken off, especially ASP.net. The question is, are they going at full throttle in the wrong direction?

One of the primary goals of every developer should be to prevent or drastically limit the number of bugs or defects from being introduced in their source code. It is also our responsibility to write good, extensible, testable, and maintainable code. This however seems like a herculean task to many.

Generators is a concept that was introduced in Pyethon at version 2.2, back then they were unidirectional that only allowed information to be passed out of the generator and not back into it, which limited their use to simple iterators and not much else. This was changed / enhanced in Python 2.5 when both data and exceptions now can be passed back into to generator. The changes made in 2.5 allowed for generators to be used as coroutines enabling them to function in complex event-driven programming such as asynchronous I/o, games, etc.

This week i read Robert C. Martin’s Clean Code book. With so many great books already available about writing good code, the first question i asked myself was: do we really need another one? The answer turns out to be YES!