The infamous Save() method

We (a collegue and myself) had a little infight a few days ago during a pairprogramming session - I advocated for having all Save() methods being void and parameterless whereas he didn't see any problems in having them returning objects and/or taking input parameters at will.

I couldn't at that time argue my case except that I saw this as a violation of the SoC (Separation of Concerns) principle - and why force the consumer to handle a return value if the consumer doesn't need to have one? The discussion grew a little ugly at some point but yesterday just before leaving the office we talked it over again.

It turned out that my collegue's experienced with TDD for various reasons has not been overly positive - having to figure TDD out for yourself without having some sort of experienced mentor inhouse will lead to frustration in 95% of all cases once you try to use TDD in a real-world scenario. We argued about having a signature of Save() methods in general and I understood my own reservations when we discussed what would happen once the signature of the Save() method changed because we i.e. wanted to introduce a new parameter in a call to Save() - example:

public void Save(string a, string b, int c)
{ ... }

was to be extended with:

public void Save(string a, string b, int c, List d)
{ ... }

What happened in his mind was that the compiler would burp on all places where the Save(a, b, c) was used so you had to change the code of your tests in all places.

What happened in my mind was that you had to change all working tests using the infamous Save() method because you changed a single signature of a method. This is bad because

1: The time spent maintaining your tests should be kept at a minimum
2: You could be mislead to work around changes in your model to avoid having to alter your tests to reflect that change - and THAT should ring the alarmbell.


Conclusion:
1: Having simple method signatures should be a goal in itself to avoid breaking the code of your tests when you want to introduce new functionality and parameters which needs to be carried around in your application.

2: Do use objects to carry around parameters for you. Less code is needed and the readability of your code is much higher. Having i.e. an object carrying 10 primitives around your model is much more extensible than having to extend every class with a property for param #11.

3:
You should not be afraid of having "dead" objects in your model and view which can only contain data. They are keeping the numbers of properties and overloaded methods in your application to a minimum :o)

Related articles:

TDD antipatterns (I don't agree to every one of these but it is a good checklist)

This guy suggests best-practises for API design:
How to design good API's

Definition of quality

I just started in my new job - I am about to work with 3 highly intelligent and competent software developers plus whatever consultants and external ressources we add to our pool of ressources.

I have a few personal goals with this new job. One of them is to try to ask the questions which are impossible to answer correctly but nevertheless make people think. So I took the initiative and gathered our small crew to a little session which was supposed to be a wrap-up of all the things I had worked on in my previous job. What had I been doing, what had I learnt, what kind of personal insight had I gained and so on... Primarily I wanted to focus on the process and not so much on tech-stuff and implementation of projects.

I started out and soon I had wound up all the failures and fuckups of my previous projects... Yes, I have made lots of weird, unmaintainable sicko-code which however had made the business happy and had earned loads of money to the company. I started thinking: "What is quality?". Ooooooohhhhhmmmmmm........ A sudden insight appeared before my eyes and I felt it coming: "Define quality!". I asked the other guys when we came around the subject in our talk and asked them to define quality. They went quite blank and I knew I hit something. When I asked them who should define quality one of them said without blinking: "Well... in this firm we do..."

I have thought a lot about what quality is after we had our talk. What is quality? As a software engineer I tend to focus on issues such as code readability, ability to extend, logging, choice of technology and so on. For a guy working in a sales departement I think quality can be summed up to: "Can I earn a shitload on money on this feature?" He couldn't care less that I use LINQ or NHibernate to fetch data from the database. He only cares that when somebody clicks "Confirm order" the order is stored in a way which makes it possible to invoice the customer.

It makes a lot of sense to me to define quality as the least possible amount of effort spent to keep the sales departement happy. Why should we measure things differently? If they are happy it means they are able to sell - and if they are able to sell you know you will also be payed for your work at the end of this month. I regret that I haven't found any better definition because it actually promotes cowboy-coding to be an legal approach to new software in about 80% or 90% of all new business cases!! Oh my God...

Somebody save me - how can I go to work tomorrow knowing that I am obliged to be writing sloppy, unmainainable code in order to have a short Time To Market which will enable Sales departement to earn a shitload of money because we were first movers on the subject?

Test-Driven Development and the quality issue

There has been quite a lot of fuzz lately regarding Test Driven Development (TDD) - I have seen a number of posts where poeple are asking if the maturity of the tools on the market make old-school TDD obsolete. I have also seen posts where Ben Hughes asks if TDD really ensures quality.

That made me think about the term "quality" - what is software quality seen from a customer's point of view and how can we convince them that the software we produce are better than the one of our competitors?

I don't really think you can measure very much out of TDD in a sense of software quality seen from a customer's point of view. I mean - do you really care how Microsoft develops Windows XP and Windows Vista? I couldn't care less - neither do our customers as long as our sh** works every time. Even when our customers have a negative experience because they are unable to fulfill whatever task they were set to do because we as software engineers have failed to deliver - do they start to ask questions? Not really - they start looking for the products developed by our strategic competitors on the market to look for a replacement of the crap we have convinced them to install on their harddrive.

The principles and paradigms on which a software product has been built upon can and should never be a quality metric for our customers. They will never care anyway. TDD is just one (very useful) tool out of many when we develop software. In terms of quality it should only be a metric inhouse whether or not our software has a certain degree of code coverage for instance... We must not be mislead to believe as developers that anyone else but us really care what tools are in our toolbox!