Dubious Arguments

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.

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

Utility software network outage monitoring systems

Dental insurance

Private equity

Financial data collection

Credit risk assessment (I was purely on the operations side for this one so domain was irrelevant)

Merchant marketplace

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.

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 inDevelopment|Comments Off on App.Config and Transforms on build

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.

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.

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.