Addicted to Interfaces: Jackie Says No!

Ok, so I previously stated that adding ‘Impl’ to the end of your service implementation would get you on my ‘people to kill list’, and that was all I had to say.
Well, although I don’t have anything original to say on the topic, I feel like elaborating.

Disclaimer: if some points sound like lessons in egg-sucking, then that’s because some readers may be currently learning to suck eggs; I’m not necessarily assuming that you need to be told : )

I’m coming at this from a Java perspective – although it probably applies to many other languages too.

Preamble

Java gives us concrete types, abstract types, and interfaces. Bear in mind that…

  1. If java supported multiple inheritance then we wouldn’t need interfaces – an abstract class full of abstract methods would make interfaces redundant if not for that shortcoming.
  2. You don’t need a Java Interface to have an interface. All classes with public methods have an implicit public interface which looks exactly the same as that of a Java Interface.
  3. At compile time, clients of an interface don’t care whether it’s an implicit public interface on a concrete class, abstract class, or an actual Interface type – the whole point of interfaces (and polymorphism in general) is that client code shouldn’t even need to be aware that they are, or aren’t, using an Interface / concrete class / abstract class.
  4. Some time back in the day, someone invented sliced bread. Since then, IDEs have been able to extract interfaces – or convert between class interfaces & actual Interfaces – at the click of a button.

Continue reading

Posted in coding, java, software | Tagged , | 1 Comment

Sunday nugget 003: Service s = new ServiceImpl();

200_s

If I see the suffix ‘Impl’ in your class definition, you go on my ‘people to kill’ list.    That’s all :)

**edit**  Ok… that’s not all. See:  Addicted to interfaces

Posted in coding, software | Leave a comment

Sunday nugget 002: There is no such thing as a ‘BDD test’

Neater_9975Using JBehave or Cucumber (or whatever) does not make a test a ‘BDD test’. There is no such thing as a BDD test.

BDD is a way of developing, just like TDD (albeit typically at a more abstract level). Frameworks like JBehave and Cucumber can aid you in your behaviour driven development.

Labelling arbitrary tests ‘BDD tests’ just because you used a given/when/then syntax, completely misses the point of BDD – and devalues any real BDD that you might be doing.

And finally, as an aside, if you value your ‘BDD tests’ for any living specification they offer – then that living specification is precious! Don’t ruin it with tests which don’t serve that function in a clear and concise manner. Especially if the only reason you’re adding those tests is because ‘we do BDD’.

Posted in Uncategorized | Leave a comment

Don’t break down user stories like a plonker

Nicholas LyndhurstLets suppose the product owner gives us a story something like this:

I want to process incoming xml payloads with an encrypted block of elements contained within the unencrypted main body.

And lets suppose when we look at what that entails it’s something like this:

  1. Edit DTD to accommodate encrypted block (which will be JSON containing key value pairs to then be substituted into well formed XML as if the encryption hadn’t been used).
  2. Identify whether this payload is of the encrypted variety or not.
  3. Check that the client is allowed to use this new partially encrypted service.
  4. Obtain encrypted private key from DB, decrypt it, decrypt the AES key in the payload, use the AES key to decrypt the rest of the encrypted block.
  5. Basic validation of elements that have been decrypted (probably just that they are all present).
  6. Create a well formed XML document by putting the decrypted JSON key value pairs into their correct places within the XML document.
  7. Process the XML document as we normally would do before the new encrypted service.

Now lets suppose that this all looks too big to fit into 1 sprint. We should break it down into smaller user stories. Fine.

  1. Lets pull out the decryption tasks into their own user story.

Er… ok. How are you going to go about that? Continue reading

Posted in coding, software | Tagged , , , , , , | Leave a comment

Sunday nugget (or facepalm) 001: Jenkins != Continuous Integration

This shouldn’t need to be said, but it does.inconceivable

Unless you integrate your code continuously (i.e. at the very least every day), then you are not doing Continuous Integration – regardless of whether you have a Jenkins/Hudson build run on commit, or not.

 

Posted in Uncategorized | Leave a comment

Baby steps towards agile development 001:

spaghetti1) Quality

Disclaimer: This stuff applies 99% of the time.

You can’t exhibit agility in your software development if you write poor quality code. The same goes for tests (maybe I’d better make that step 1.5!).

A primary facet of agile software development is the agility to change direction quickly. You can’t do this when change is too expensive. Poor quality code makes extension difficult and therefore costly. Poor quality code makes refactoring very difficult, and therefore costly. Poor quality code can make automation harder (we’ll get to that later), and therefore costly.

Poor quality code can also make it more difficult to ensure that you have working software as much as possible (it’s often good to be able to demonstrate what you’ve got so far to the client, and to get feedback based on that). Your team should all be familiar with, and understand SOLID principles & the benefits of their appropriate application.

1.5) Unit Tests

Disclaimer: This stuff applies 99% of the time.

I shouldn’t really have to say this, but… Write tests! and make sure they’re good ones. You can’t refactor fearlessly without a comprehensive set of automated unit tests, as a minimum, functioning as a safety net.

The agility to change rapidly means the agility to refactor without fear. You ideally need tests to cover every required unit of functionality, and those tests need to be good quality tests – poor tests are worse than no tests as they cause fear, uncertainty & doubt. At best, poor tests are an unnecessary maintenance cost – often they are far more dangerous in the way that they mislead.

A Test Driven approach to development (TDD) is often ideal – done correctly you should only ever have code that has a specific reason to live, and that code will be written in a testable way, and will be tested out of the box.

You should never need to go to bed at night worrying whether you’ve broken something!

Bearing in mind that unit tests constitute a maintenance cost, there can be such a thing as too many tests (as well as overly fragile tests, etc, which I won’t go into here) – something I’ve heard referred to as ‘TDD OCD’. For example, if a particular ‘unit’ of functionality has no branching logic, then it does not need it’s own test – it is perfectly acceptable to test that unit indirectly as part of another, broader test.

See http://osherove.com for some good unit testing resources.

If you don’t have good  test coverage (and by that I mean that you actually test – rather than just cover) then you are almost certainly not going to be agile in any meaningful sense of the word.

Imagine an acrobat – with a safety net he can show off his amazing agility to it’s fullest, and should he fall he can simply climb back up the ladder and try again. Without a safety  net he might show amazing agility right until he falls and dies. Development without such a safety net is equally reckless, and in reality that means that any real agility will not be realised, due to  fear.

Posted in coding, software | Leave a comment

Agile is for losers…

…real men embrace agility.

The development world seems to be full of ‘Agile’ pretenders. If you were to object to my saying that ” there is no such thing as ‘Agile’ ” then I’m sorry to say that there’s a reasonable chance that you too fall into this category. Let me explain…

There is no ‘Agile manifesto’. There is a ‘Manifesto for agile software development’, which lays out some general principles which one might like to follow in order to help them develop software with agility. Of course it seems entirely reasonable to shorten ‘agile software development’ to simply ‘agile’, but herein lies the same problem we see in many other aspects of our day to day lives – words are allowed to be abused and end up losing any sense of meaning. Worse still they end up meaning something entirely different than they did to start with – for example, the word ‘trolling’ as is commonly used in the mainstream media these days has almost no resemblance to its original meaning. We’ve lost a useful word. The ‘agile’ community has suffered an even worse fate as the word ‘agile’, across sweeping parts of the industry, no longer has any relation to the concept of agility. Not only have we lost a useful word – we’ve managed to pervert the philosophy of agile software development as it is understood in many people’s minds.

We’ve reduced agility to mindless process, wrapped up in a pretty new vocabulary. An alert mind will spot the obvious paradox and endeavour to educate themselves to correct their misunderstandings. A keen but less alert mind will suffer the pain of contradiction and endure the inevitable failure (or at least a hefty dose of strife) as long as it takes them to realise that something is wrong; At which point they will deduce either that ‘Agile’ is a fraud, or that they too need to educate themselves so that they might do it properly.

A worrying but very common (in my experience, at least) trend is that of a third kind of mind. This mind persists in having faith that such a prescriptive process (invariably involving moving cards around a board) followed obediently, despite it’s apparently voodoo nature, will yield some kind of magical gain in productivity. These people suffer just like the other 2 kinds I’ve mentioned – but this time they are doomed to forever suffer the pain caused by trying to resolve contradictions, thanks to their stubborn belief in magic.

So, lets see if you’re an agile pretender …

Posted in Uncategorized | Tagged , , | Leave a comment