Impress your CTO – Define your own NFRs

In the last instalment I talked about unspecified requirements. These are the ones that your product owner takes for granted: Of course the system should export to Excel; of course it should authenticate with Facebook; of course the system should load pages blazingly fast irrespective of how much data is thrown at it.

The most common of these unspecified requirements are the Non-Functional Requirements (NFRs). And the most common of these NFRs is “how long should the response time be”. So I find it surprising that response times are very rarely (if ever) mentioned during requirements definition work. Avoiding the topic early in the project is a sure way to have problems later on in the lifecycle.

It’s not uncommon to experience a conversation like this:

Sales: “This software is dreadful, it just took forever to load the dashboard in a crucial demo”
Dev: “Let’s see what’s up… oh yes you created a wizzabanga with 38 different permutations”
Sales: “Well yes of course I did. Then it took forever to load into the dashboard. Your software sucks.”
Dev: “But we didn’t have any NFRs”
Sales: “What’s an NFR”
… some tedious conversation ommitted ….
Dev: “So give me an NFR”
Sales: “OK, I want the page to load up in 200ms even if I’ve got 1000 wizzabangas each with 100 permutations”
Dev: “Hmmm… going to cost you”

etc

It’s meaningless to ask your user base for open-ended NFRs. Clearly they want everything to be really fast and really easy and really secure and ready next week. Much more useful would be for you to set out some reasonable NFRs that you think are deliverable in a reasonable timeframe and, even impose some sensible limits or warnings in the system to ensure those NFRs are supportable. Then at least you have an NFR, even if it’s one that you created.

For example if you think it’s reasonable for the page to load “fast enough” if your wizzabanga have up to 10 permutations then either impose a limit in the UI, or even just a sensible warning, “e.g. we recommend that you have no more than 10 permutations in your wizzabanga. You can add more but please note that you will need to be patient when loading larger wizzabangas.”

Impress your CTO (3)

Imagine the following conversation between a product owner and developer

Product Owner: “I want a CRM system”
Developer: “What does that do?”
PO: “It’s a customer database that lets me manage and report on my communications with my customers”
Dev: “That sounds easy, I’ll build you one this iteration”

One week later …

Dev: “Here you go. You log in here and here’s a screen where you can add a record for each customer. When you click into a customer record you can also add some notes for each time you’ve talked to them”
PO: “Wow, you did all that in a week, awesome. Now let’s add in the ability to make some notes for future calls that I need to do and a screen to show what tasks I have upcoming”
Dev: “No problem”

One week later …
PO: “This is so cool”

Brand new projects often start like this. But it doesn’t take long for fatigue to kick in. A few more iterations and all of a sudden you’re getting bogged down in details like:

  • Download to Excel
  • Upload from Excel
  • The fact that you should really be validating postcodes
  • And show the location on a map
  • And have better collaboration facilities
  • And handle customer segmentation
  • Ability to handle email templates
  • And initiate voice calls
  • And route incoming calls to an appropriate agent
  • And let someone apply a credit to a customer’s account
  • etc, etc, etc

At this point you start to realise why no-one sane would build their own CRM.

The Importance of Unspecified Requirements

You see you have functional requirements and you have non-functional requirements. But beyond all of these you have the unspecified requirements. These last ones are really important because your product owner considers them so obvious that they aren’t worth mentioning. Of course your CRM system has to handle loading records from Excel – only a buffoon would not know that!

The solution isn’t to insist on 100% detailed specifications before you start building. That way another type of madness lies. Nor should you consider your job well done because each week you have built what your customer asked for. The best developers are the ones who deliver the best working software, which is not as simple as building what was written down in the spec.

Worry about their unspecified requirements before you get too far down any path. It doesn’t have to involve much coding (if any). If someone asks you to build a CRM then do a sort of throwaway prototype first. Not one that involves any coding. (I’ve seen some great throwaway prototypes written using Excel). Why not get a one-month license to Salesforce (or whatever). This is a great way to get to see really what features they value, where their frustrations are etc. Then if you discover that Salesforce is the right answer for them then thank your lucky stars that you’ve had a narrow escape from attaching a massive bespoke millstone round your neck for the rest of the time with your company. And if you discover that there is something really special about your requirements, well, then you can build a truly great application that really addresses the real problems your users are facing.

 

How to make 3000 look like 8000, or #marketing

See below how CarGiant, a UK-based retailer of used cars does it.

First off, the organic search results:

Car Giant organic search results

If you search for Car Giant they have already anchored in your mind that they have over 8000 vehicles

CarGiantHomePage

So now you land on the home page and note how the “over 8000” has now changed to “up to 8000”. That could be a whole lot of a smaller number. So let’s do a search for all vehicles up to the maximum price available.

CarGiantSearchResults

And there you go, just under 3000 cars. Which is definitely “under 8000” as promised, but by this time you’ve still got in your head that Car Giant is a truly giant organisation with 8000 or more vehicles to sell you.

See also https://en.wikipedia.org/wiki/Anchoring#In_negotiations

 

Valuing Sweat Equity, 1100 AD

Find a valuation for a startup is a thorny and emotive subject. How much is the idea worth? How much is the founder(s) working for many months without any income worth? How much is your advisory board worth?

So I enjoyed coming across this keep it simple approach from Genoa around 1100AD

From David Abulafia, The Great Sea, p277

Often … merchants engaged in what they simply called a societas, or ‘partnership’, where a sleeping partner would invest three-quarters of the total and his (or her) colleague would invest one quarter, while also agreeing to travel to whichever destination had been agreed, and to trade there. On his return, the profits would be divided in half … [A]nother arrangement became even more common: the commenda, where the travelling partner invested nothing more than his skills and services, and received a quarter of the profits.

Using this model you come out with the “sweat” part of the valuation being worth between 25% and 33% and the “investment” part representing the rest. Of course this doesn’t take into account that in 1100 being the travelling partner put you at risk of serious bodily damage rather than just a few all-nighters and stressful pitches. Nor does it take into account the fact that there are bound to be differences between fitting out a ship and cargo for a sea voyage in 1100 and turning a software MVP into a self-sustaining business.

But (coincidentally?) the relative weights between cash and sweat do feel about right.

Impress Your CTO (2)

People expect software to “just work”. You can guarantee that it won’t
“just work” when someone decides to throw more data at than you expected. So my 2nd tip is:

Enforce Sane Limits

From a developer point of view it makes sense to think in terms of 1 to Many or Many to 1. Why put in extra work to enforce some limitation when you can have unlimited flexibility for free?

Because the real world doesn’t work that way and it’s more important to model the real world than it is to create infinite flexibility. Some good reasons:

  1. Usability
  2. Performance
  3. Commercial reasons

Usability

The more “many’s” in your one to many, the more UI real estate you need to think about. Pagination, sorting, searching, exporting lists to Excel. Maybe favouriting so that people can shortlist the results because they can’t make sense of the whole list. Nothing here is super-complicated to code, but given that the scarce resource in most tech operations is developer time, as a great developer you will be ensuring that you are spending your valuable time on the most value-add activities.

Performance

Be honest. You aren’t about to write comprehensive automated performance tests. If you allow people to add unlimited items then eventually someone will do so and, probably sooner than you expect, you will experience serious performance issues. Which then means that you need to be spending valuable developer time addressing those performance issues because by the time you have enough traction to have performance issues you aren’t going to be able to withdraw the poorly performing feature [*].

Commercial Reasons

Maybe a surprise to see this as a reason but it may be the one you would do best to remember. The simple point here is that if the standard version of your product allows the user to add up to 15 items to a Thingamy then not only do you lower the risk of performance issues etc but you have a built-in mechanism that your product managers can use to upsell your customers to the next subscription level: “You want to handle more than 15 items? Let me put you through to our Enterprise Sales team”. If there is demand for the feature and customers will pay for it then fantastic – it will be a great feature to spend some real effort and attention to and give it a stunning user experience that performs really well.

Conclusion

I’m not saying to do anything complicated in your database. Leave the database handling a 1 to Many relationship. Just put check somewhere in your business logic. Next time you are discussing a feature with your product owner and you are thinking about the many side of the object model, just ask the question: “Would 5 be enough?”

[*] This is a case of “do as I say, not as I do” here. In my own side project which allows a user to merge and stitch together data from different Excel files I didn’t impose any limits. I asked some friends and family to test it and the second thing my brother did was try to crash it. It worked. So now I’ve implemented some limit checking.

Impress Your CTO (1)

There are plenty of developers who will happily build the functionality described in a set of requirements.

That is fine as far as it goes. We need requirements and we need to deliver working software to satisfy requirements. But it takes a LOT more than just this to build decent software products. Not only are there a myriad different ways to satisfy a set of requirements, but even more exciting, in today’s agile (small a) world developers have a great opportunity to co-create products with their product owners.  And in the process to become great developers, not just good developers.

So I want to share some personal views on what you should be thinking of to become a great developer. I’m taking for granted that you know your framework, you know how to use Stack Overflow and that you write good unit tests. I’m going to be talking about the other stuff. The stuff that, in my view, distinguishes great developers from, well, just developers. The stuff that, when I see it in my team, helps me sleep more soundly, knowing that the codebase is in good hands.

Here’s the first one.

Learn your database

Your framework is great. It has a lot of really cool abstractions so you can program away without having to (amongst others) handle all the tedious details of writing SQL [1].

Time for a story.

A product owner was launching a new product and wanted to give the impression that it had been around for a long while. A reasonable request, I mean, who wants to know they are being billed with Invoice #1. The solution was to use a higher number. So the first invoice would be #225678 rather than 1, for example.

This is trivial to do with any RDBMS I’ve seen: you just set the auto-increment to the appropriate number, rather than start counting from 1.

Not in this case. The developer didn’t want to get involved in proprietary database commands. He decided to use a parameter, let’s call it INVOICE_OFFSET, to adjust what someone would see on the UI. Sounds simple enough – set INVOICE_OFFSET to 225677 and every time you show an invoice number on the UI or in an email add INVOICE_OFFSET to the database id. Likewise, subtract before you do any CRUD operations on the database.

Can you see where this is going?

It was fine while there was only one developer involved in the product. It soon turned into a bit of a mess when new developers came on board and weren’t expecting this INVOICE_OFFSET idea. For example in a REST situation, would you use the database ID in the URL? Or use the ID that the user would recognise? And then when you were interpreting the ID in the URL, is it a database ID or an adjusted ID?

True story [2].

I fully accept that writing SQL by hand is horrible and so I am very grateful for ORMs for abstracting that away. But too many developers have gone too far the other way and treat the database as a black box. Or go as far as learning about indexes.

Databases are pretty awesome pieces of software, see what else they can do to help you build better applications.

 

[1] Hell, you could even write an application that you can then easily port from one database to another should you want to. Though if there ever was a case of YAGNI, having an app that you can port between databases should be a top contender.
[2] To be fair, I don’t think there was ever a production issue where one person could inadvertently see someone else’s invoices, but it was certainly a PITA during QA time.

I Wrote a Software: My Tech Stack

I’ve been writing recently about a side-project of mine that I’ve been doing to scratch a couple of itches I have: Using Excel as a Collaboration Tool in an Enterprise Setting and Seeing what all the fuss is about Haskell.

I started off, reasonably enough, by trying to write a web app. But getting started with anything in Haskell is hard enough: getting started with a website was a nightmare [1]. So I made a virtue of necessity. I figured if I’m going to make it easier for people to collaborate with Excel then what is the most natural way for people to collaborate with Excel in real life? The answer is simple: by sending email attachments.

So I forgot about any web interface (for now) and just concentrated on working with Excel Attachments on Emails. It meant I could just focus on learning Haskell and also forced me to work in a way that is going to be more natural for anyone who might use the service. And also it turns out that I’m bang on trend with this whole “No UI” movement [2].

In this post I’m going to get into what I’m using on this project and why:

  1. Ubuntu. I run this on the server simply because I’m used to using Ubuntu on the desktop from the past. I’ve run Ubuntu in production for a long time and it’s fine for me. (I’ve also run CentOS and Windows and going back far enough HP-UX and Solaris, but Ubuntu just seems… nice).
  2. Linode. Not all that much thought on this one. I’ve used AWS in the past and find the interface unbearably complex. I’ve used Rackspace Cloud with a lot of success. But I’ve also been curious as to how Linode and Digital Ocean stack up. I asked Twitter and I got an answer from someone in the Linode community. And so here I am.
  3. Postfix/Dovecot. I never imagined running my own mail server. I originally wanted to run all the email through Gmail. But I kept getting blocked for having a script running against the Gmail servers. In the end I figured I may as well run my own. Remains to be seen how well that works out. And (perhaps coincidentally) the best guide I could find to setting up Postfix/Dovecot was from Linode.
  4. MongoDB. I know that Mongo is no longer the cool kid on the block. But given that my use case for data storage is pretty straightforward, but I expect to need to store large Excel files, Mongo seemed neat. I’m using Mongo as a queueing system as much as a persistent data store.
  5. Haskell. For the heavy lifting. Learning it has been a long, hard slog. I must have read Learn You a Haskell 15 times (I even bought a copy). And also Real World Haskell several times. But you only really learn by doing and for me the best doing came from trying to follow Write Yourself a Scheme and then by trying to figure out how the HaExcel guys did it. Hat tips must also go to HaskellLive for getting an environment set up (though this now seems to be superseded by Stephen Diehl’s excellent write-up).
  6. Plain vanilla Ruby. Because with the wealth of gems in the community you can do a lot very easily.

[1] My brother who also works in tech bought me a copy of Building Web Applications with Haskell and Yesod. He thought that Haskell and Yesod were two individuals who were doing the teaching. This is in stark contrast to Ruby which I learnt from Alan Bradburne’s excellent Practical Rails Social Networking Sites.

[2] A cynic may say that mailing lists have been doing this for donkeys years. To which my reply is that the surely this validates the use of email for sending instructions around.