resist implementation

There was a funny situation in my team recently. During the end-of-iteration demo there was a discussion about a new feature. The arguments in favor of a feature were mostly: it’s **cheap** and it **would** be…

Over the years I developed a natural resistance against implementation. It’s quite weird given that I do software for living, no? Here is my story:

Cheap? There are no cheap features.

Every feature means new lines of code. New lines mean more software that can have bugs. New lines mean more code to maintain. New user stories may also bring some organizational burden like tracking, testing, meetings, discussions, agreeing on details, etc.

Would? Adding features based on speculation is risky.

There is a fair chance that speculated feature is not that useful or doesn’t really appeal to the user. Well… this is something I will find out in future.

It’s better to wait for user’s feedback. It’s usually better to implement something very simple and consider it as a starting point for a discussion with a user.

I implement features only if I know they’re needed. Although it’s usually fun to write good software, I’m quite good at resisting implementation.

Finally, it’s wise to remember that it all depends on the software at hand. For example, some speculation is required when implementing spanking new killer-app that is about to win the market with brand new ideas.

is private method an antipattern

After a conversation with my friend and after a cursory google search, here are my thoughts:

‘Private method a smell’ seemed to be ignited with the birth of TDD. Test-infected people wanted to know how to test their private methods. Gee… it’s not easy so the question evolved from ‘how‘ into ‘why‘: Why to test private method? Most of TDDers would answer instantly: don’t do it. Yet again TDD changed the way we craft software and re-evaluated the private methods :)

Test-driven software tends to have less private methods. Shouldn’t we have a metric like: private methods to public methods ratio? I wonder what would be the output for some open source projects (like spring – famous for its clean code).

So, is private method an antipattern or not!?

If the class is so complex that it needs private methods, shouldn’t we aim to pull some of that complexity into its own class?

The code never lies: We looked at several distinctly big classes and put their private methods under magnifying glass. Guess what… Some of the private methods where clear candidates to refactor out to separate class. In one case we even moved whole private method, without a single change, into separate class ;)

Privacy may be an antipattern. Look at your private methods – I bet some of them should be public methods of different objects.