Tag Archives: design

Schauderhaft by Jens Schauder

I recently discovered the blog of Jens Schauder thanks to a colleague, and wanted to note links to some of the posts I found interesting.

Boolean Stack – an idea of simplifying complex boolean rules by expressing them instead via collections of “allowing rules” and “denying rules”.

Developing for Supportability – exactly what it says, including how important it is to make it easy to stop and start your application.

8 Reasons why the Estimates are too low – the top 2 of those I have experienced are: having estimates prepared by developers familiar with the area of the system, and then expecting completely new developers to take the same amount of time; and estimates having to be made with nowhere near enough information available.

Another extra one I have seen is the assumption that all developers will spend 80-100% of their time on their tasks, which doesn’t allow enough time for meetings, design and code review sessions, etc. Starting at 80% would be fine if there was some effort to monitor whether this was realistic and then adjust it if necessary.

One Database for Every Developer – enough said. It’s not as bad if your application only reads from the database, but it’s still a pain at times.

About Packages – how packages aren’t always used effectively. As mentioned in the comments, I also see packages too often used as sorting containers e.g. “exceptions”. I think if we paid more attention to this, we’d also put more thought into the visibility modifier of our classes instead of just making them all public.

Breaking Dependency Cycles – what it says it is.

Fixing the Singleton – why singletons should only be used via dependency injection.

How to Design a Good API and Why it Matters

An interesting presentation from Joshua Bloch – How to Design a Good API and Why it Matters. It’s exactly what it says it is, with plenty of examples from Java.

Some of the interesting points he makes:

  • an good API can be an asset, but a bad one a liability – you have only one chance to get a public API right
  • Will Tracz’s “rule of threes” – write 3 plugins/interface implementations before release to make sure you’ve got the interface right
  • bad design decisions can limit performance
    • (an example I see sometimes is “Thing getThing(K id)” provided, when I want to get multiple Things – it would be good to have e.g. “Thing[] getThings(K[] ids)”
  • Methods should be failure-atomic – succeed or fail, not leave things in some half cooked state
  • Provide programmatic access to all data available in string form
    • otherwise people will parse it – example given of stack trace in Throwable
  • Use consistent parameter ordering across methods
  • Easy to make mistakes with long lists of identically typed parameters
  • If too many parameters, make a helper class to pass them in
  • Return zero-length lists, not null
  • Overuse of checked exceptions causes boilerplate
Finally, another rule I’ve heard before is this:

simple things should be easy, complex things should be possible

Utility classes

I’ve long been wary when I see utility classes being added to projects, and I recently came across this article on using extension to avoid proliferation of utility classes.

Sometimes utility classes are fine (I’m a fan of Apache Commons Lang, for example), and extension often isn’t possible or doesn’t fit for various reasons. But once in a while I see utility classes and can’t for the life of me work out how it could have seemed to be a good idea to create them.

Why sign in?

There are some great articles over at User Interface Engineering about design mistakes in the area of user account sign-in:

I’ve always been frustrated at having to register to be able to buy things online, so I’m glad to find that I’m not alone in my frustration. The article is quite old, and I’ve seen “check out without registering” options pop up on some sites in the past few years so things are improving.

I think that such an option is a must-have for non-major online retailers, as it’s all-too-easy for a potential customer to just go elsewhere to a site that offers the option or a major site that they already have an account with.

Thankfully (by now, at least), most of the mistakes listed are less common but there are a few that are still common and particularly annoying:

  • Mistake #9: Not Telling Users the Requirements for Username and Password Up Front
  • Mistake #10: Requiring Stricter Password Requirements Than The NSA
  • Mistake #12: Not Returning Users to Their Desired Objective

There’s also the inverse of #10 which is still pretty common – sites limiting passwords to a short length and alphanumeric only.

Usability vs. security

  • Mistake #13: Not Explaining If It’s The Username or Password They Got Wrong

This rang some alarm bells for me (as it’s a security measure), and it turns out that it did for a few others as well. The author has acknowledged this with some further thoughts on balancing usability and security while considering what level of the latter is appropriate for the context.