Skip to content
Finding better ways of developing software

We have to be good at being wrong. Architects can help

April 28, 2006 by Artem

Anssi Piirainen raises the idea about the need to be good at being wrong in order to create good software. The core idea is good - you have to be ready that the first implementations might later look not very well. However, Anssi also presents the micro case study describing the problems with the "just-in-time design" approach. The changes required appeared to be unexpectedly difficult to not that experienced programmers.

Just-in-time design is not a silver bullet. It is just yet another good tool that can be rather useless until it is used with the correct support practices.

Mocks, stubs and fakes

April 25, 2006 by Artem

I am rather new to the Test-Driven-Development (TDD) and continuous testing in general. Therefore I quite often experience the terminology difficulties: how to call fully functional alternative object, how to call almost empty stub objects, etc. It looks like I am not alone.

Martin Fowler highlights the Gerard Meszaros's proposal:

The generic term he uses is a Test Double (think stunt double). Test Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists:

Good design ghosts

April 24, 2006 by Artem

I can recall several cases, when a seemingly clean'n'simple class appeared to be a huge and difficult to debug entity with loads of underlying asynchronous logic. The simple and small public interface hides the implementation details and according to the good Object-Oriented style all the underlying details are private. Or is it a good style to hide the implementation details into many private methods?

As it often happens, the problem comes from a good idea overused to the extent, where it inhibits another good idea. The encapsulation makes it easy to use your classes or systems externally, but it should not make you forget the internal structure of the class. As Michael Feathers tells

It often means that there's some other abstraction hidden away inside the class that might be useful to pull out.

Waterfall in schools

April 23, 2006 by Artem

Grig Gheorghiu tells about the funny experience of interviewing the graduates for a QA position. All of the candidates have been taught only a waterfall method.

He said they spent a lot of time writing design documents, and since they *only* had one semester for the whole project, they almost didn't get to code at all. I couldn't help laughing at that point, and I told him that maybe that should have been a red flag concerning the validity of the Waterfall methodology.

Process over the individuals

April 9, 2006 by Artem

Individuals and interactions over processes and tools © agilemanifesto.org

Lately on a Russian programmer forum I've read a story about the usual victory of a process over the individuals.

One software development company had Windows and Unix stations. As a result from time to time the wrong endline characters leaked into the repository and caused the build breaks. There were two ways to overcome the problem:
1. To oblige everybody to check the files before the commit

Why premature optimization is the root of all evil. In the management language

April 8, 2006 by Artem Marchenko

The program optimization is performed in order to reduce the execution time, memory usage, bandwidth or some other resource. Optimization essentially means sacrificing the clear, simple and understandable code architecture. As a result the level of complexity increases, debugging and restructuring becomes more time-consuming and more expensive.

It is simply a lot cheaper to get a clear working and testing code before the start of the optimization. As a side effect, a set of unit tests (if you practice them) will protect you from the potential regression coming from the optimization actions.

Being evil is expensive

April 5, 2006 by Artem Marchenko

Once upon a time in a continent far-far away (from Europe) there was a mighty spreadsheet software vendor called Lotus Development Corporation. Their product Lotus 1-2-3 dominated the niche with its almost 100% market share. There was a neglectibly small competitor product named Microsoft Excel. The Microsoft's product better met user needs, integrated well with the word processor and in general was a good product. Unfortunately the Lotus'es overwhelming user base left not a lot of chances for any competitor whatever good he was.

The Microsoft worked real hard to lower the enry barrier. They mailed demo packages by post, built the Lotus-to-Excel convertors, even created a special version of the Windows OS, that could be started without the installation and could run the MS Excel trial only - pretty much everything, that could eliminate the trialing efforts. And the most cunning trick of the Microsoft generals was to introduce the really good Excel-to-Lotus convertor. Yes, you heard it right, Microsoft released the tool that customers could use to switch back to their old good Lotus 1-2-3 whenever they decide that Excel isn't worth any further trials.

Selling Test-Driven Development to your boss

March 29, 2006 by Artem

Managers don't speak C++, refactoring and some of them don't trust the programmer's "feelings". To sell TDD to them, we have to speak the management language of costs, deadlines and delivery delays. Apply some management language and you'll be able to start the TDD.

Killer argument tips:
1) Extra testing saves at least some time of the final test round
2) Extra testing improves the code quality at least a bit
3) If extra testing is applied to the most important components and interactions, it takes not that scary amount of time
Therefore even in the worst case the time spent on the extra testing will be partially compensated with the better quality and smaller final testing efforts. And in the best case, both quality and delivery time will be improved significantly.

Testability as the design metric

March 26, 2006 by Artem

I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it. (Michael Feathers)

If you practice a lot of unit testing, test-driven-development of whatever method that includes a lot of testing, you have to spend a lot of time on it. And most of time you have to do the testing-related work before the problem happens and before anyone is affected. Certainly it is good to capture the bug early, before it hurts anybody, but the need to do the "extra" work in advice introduces the temptation to "just tweak this small feature and test it if the problem arises later".

Minimize the review burden by applying the review on a smaller bits of code

March 26, 2006 by Artem

Peer code reviews are known friends of a good code quality. Many of the agile methods strongly recommend them. XP as usual goes to the extreme point and offers the pair programming practice, when the reviews are performed continuously.

The usual problem with the code reviews (unless you practice the pair programming) is that they are often performed after writing a big block of code and reviewers can concentrate on the micro level issues like coding conventions and style. It is important to enforce the common conventions, but it would be great to pay bigger attention to the code logic.

Best of AgileSoftwareDevelopment.com