Gumption Trap

So, I’ve read “Zen and the art of motorcycle maintenance” a bunch of times. I don’t feel that much wiser but I like the book and some of the ideas which it outlines.

Anyway, the best section in the whole book I think is the bit on gumption traps. Basically, those traps which wait in any task ready to suck your enthusiasm.

I’m working on a gumption trap problem right now and it’s certainly destroying my enthusiasm.

We want to upload a photo to S3 directly from the client. So the client makes a request to the server, gets a pre-signed URL and then does a PUT to that url with the file.

It all seemed to be going so well until I actually tried to do the PUT and now I’m looking at the oh-so meaningful AWS error message:

The request signature we calculated does not match the signature you provided. Check your key and signing method.

So now I have to go back and reexamine all my assumptions from the start of the task. And probably the best way to do this is implement the AWS tutorial code and check that my credentials are set up right …

Posted in Development | Tagged | Comments Off on Gumption Trap

Unit tests are only as good as the tester

So, I screwed up.

When I was refactoring some code I dropped an internal check. Basically, we are installing a profile on an entity. The previous code was checking if the new profile was being used in the system already by a different entity. I took out the check “by a different entitity” so that it was failing whenever the profile existed already in the system.

Not ideal but this is exactly the sort of error you are looking to catch when you write those seemingly pointless unit tests. Checking that the basic functionality is there. It is obvious and trivial when you write them at the time of implementation. They only become useful 6 months later when you come in to refactor code and you drop some vital business logic.

So, unit test early, unit test often and check your coverage regularly…

“Experience is something you don’t get until just after you need it.”

Posted in Development | Comments Off on Unit tests are only as good as the tester

Domain Training

When I think back on the software development jobs I’ve had it’s been across the following domains:

  1. Utility software network outage monitoring systems
  2. Dental insurance
  3. Private equity
  4. Financial data collection
  5. Credit risk assessment (I was purely on the operations side for this one so domain was irrelevant)
  6. Merchant marketplace
  7. Smart meter management

And with the exception of number 5, which was not relevant, I have never, not once, recieved any official training on the domain. At best I was pointed at a shared folder with a handful of out of date, barely relevant documents and told to get on with it.

In every company, I’ve learned about the domain from co-workers, looking at the code, bug-fixes and just ‘picking it up as I went along’. Eventually after about 3-6 months I’d have a reasonably coherent model of how things should work and then a business analyst comes over and says “Oh no, we don’t do it like that at all”.

Of course, the people who actually know how things work are too valuable to waste their time on something as irrelevant and trivial as basic, entry-level documentation.

When you think of how much time is wasted by new joinees (not just developers) learning how things should work, it does seem like a false economy.

It feels a little bit like the situation, when, as a new developer you have to set up your development system for the first time and you can end up spending a week (or more) getting everything ‘just right’. Whereas, any sane office has a standard development VM image and just rolls that out as needed.

So, free money saving advice for any managers out there. Write some entry-level documentation.

Posted in Development | Comments Off on Domain Training

Asp.Net MVC Elmah config

It took me too long to figure this out, but for anyone who needs it, here’s a default, working, ELMAH config for a ASP.Net MVC 5 deployment.

 <sectionGroup name="elmah">
 <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />
 <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
 <section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
 <section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah" />
 <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" preCondition="managedHandler" />
 <add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" preCondition="managedHandler" />
 <add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah" preCondition="managedHandler" />
 <security allowRemoteAccess="false" />
 <location path="elmah.axd" inheritInChildApplications="false">
 <add name="ELMAH" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode" />
Posted in Development | Comments Off on Asp.Net MVC Elmah config

App.Config and Transforms on build

It’s been a while since I worked with setting up a project and I’d forgotten that a Class Library, while it can have an App.Config file, that file doens’t necessarily get read by the ConfigurationManager (or Formo as I was using)

Hence 20 mins of banging my head on the desk trying to read a connection string and only getting that which was defined in the Web.Config. I don’t really want to go down the line of defining an external xml file so I just pushed the definition up to the Web.Config.

The next issue I had is that I had defined Debug and Release Transforms with an empty string in the base config. So, running a Debug build, I fully expected the transform to be applied and the app to read from the updated Web.config. But instead it just read the base Web.config.

Again, I’d fogotten that, normally, transforms are only applied when you Publish, not when you do a build. However Google to the rescue! And now my transforms are applied at build and I can test them properly

Posted in Development | Comments Off on App.Config and Transforms on build

Coding while tired

I’m doing through a simple MVC project at the moment and I wasted 45 mins trying to get Nuget to install Ninject on a newly created class library.

No matter what I was doing, it just wouldn’t work. It was creating the reference. I could see the reference in the Resources list but it wasn’t in the usual packages folder. It was hidden in some weird folder under “User/eoin/Documents”.

I can’t believe it too me so long to realise that I’d created a Web Class Library (Package) and not a standard Class Library.

45 mins.

I then went to bed and dreamt of using statements with red underlines.


Posted in Development | Comments Off on Coding while tired

Code Quality

I’ve been thinking a lot recently about code quality. Specifically, how we get from good intentions to bad implementations. Developers don’t generally go into work and think “Hurrah! today I’m going to hack together a dirty solution to a deep problem and then move on”.

Edit: As has been pointed out to me, all of this advice is assuming that you have competent developers. They don’t need to be rockstar-ninjas but they do need to have an interest in their work. If they’re more of the “implement the feature/fix the bug and move on” mindset, then there’s nothing you can do. The question then becomes, how did they get to a point where this is an acceptable way to work and how to avoid/repair the situation.

I guess, a starting point for this would be to define what I mean by quality code. Kinda like quality described in Zen and the art of motorcycle maintenance, it’s hard to define, but you know it when you see it. A stackoverflow answer has these points which pretty much nail it down though:

  • Easy to understand.
  • Easy to modify.
  • Easy to test.
  • Works correctly.

Probably the number one cause of poor quality code is a mismatch between the company needs and what the programmer wants. The company needs a product to sell, and the programmer (typically) want’s to write quality code. When push comes to shove and quality code takes too long (and it does typically take longer to implement initially) 99% of companies will mark it down to technical debt and go for the quick and dirty solution.

And you know what, that’s absolutely fine. In fact it’s needed. But when the business ignores pain points for so long, despite literally an entire engineering team saying they’re an efficency hinderance, then you start getting into dysfunctional territory. Some warning signs may include

  • your tech stack is so calcified to the “state of the art” of 5 years ago and any real change is massively painful
  • your best developers are generally unhappy/leaving
  • there’s a general miasma of helplessness
  • new features are more and more difficult to implement
  • it takes 6 months plus for new hires to be productive because your code base is so Byzantine and “special”

and so on and so forth…

No one starts out wanting to write bad code. But we do it to get features out on time. If you’re good, you mark it with  plenty of documentation on how it should be done and put it in the backlog for when you have more time. If you’re bad, it gets forgotten about and it’s just one more thing to work around.

As good developers when we find ourselves in a project where there is a lot of technical debt, it’s our responsibility to map them out, suggest solutions and with the business side, road map out a way to resolving them. Of course, just because you want to refactor that monster god class, business isn’t going to give you a weeks budget because it’s “poor quality”. You need substantive arguments about system performance and developement speed. You need to talk their language to get approval for technical changes.

Developers want good code, we just have to make the right sales pitch to the business people.

Posted in Development | Comments Off on Code Quality

Use it, Store it or Dump it.

I remember back when I was running my own business, the sheer amount of paperwork you’re get was absolutely overwhelming. I was also doing my own bookkeeping and one of the “How To” books I got had the following advice.

Every piece of paper that comes across your desk should fit into one of three categories.

  • Use it: this is something which needs action. If so, then do it. (Prioritized against other to do items of course)
  • Store it: if it’s something which you need to keep, then file it away right now.
  • Dump it: if it doesn’t need action and you won’t need it in the future, dump it, right now.

This is kinda similar to the zero inbox approach outlined elsewhere on the web and it does work quite well as long as you’re disciplined.

On another tangent, I love notebooks. A new, clean and empty refill pad has such potential… So inevitably I end up with garbled, doodle filled notes after a few months. Snapshots of details which were important right at that time mixed with more permanently important notes.

So, I’m going to change over and try and use loose leaf note paper from now on. Anything important gets put up on the company blog while transitory information gets dumped.

Use it – Store it – Dump it.

Posted in Development, Random | Comments Off on Use it, Store it or Dump it.