They say you learn something new every day.

Posts tagged ‘software’

Getting Management To Listen (27/03/2012)

Management like PowerPoint. They love charts and summaries. You need to give them something like this every week/month and then they’ll be happy.

I’m producing a communications plan at the moment at work, to try to hit lots of these at once. It’s actually incredibly important – after all, if they don’t know you’ve done it, then you might as well not have bothered.

My boss has just come back from maternity leave, and a slight danger of her deploying some micromanagement. So to get in there quickly, and keep her happy and feel in control I need to put together a regular “pack” of stuff for her. She might not read it, but at least if she can see it or know it’s coming, she’ll be satisfied I have things in control.

And actually, depressing as this is, sometimes more important than actually having it under control.

Less Advanced Than You Think (24/03/2012)

I remember a while back reading that “Listen Again” (the radio version of iPlayer) only accounts for 2% of all radio consumed. And being amazed.

This was in 2009, so it may not still be true now, but I don’t expect it’s moved that much.

The thing is: most people aren’t as technically advanced as you think. Not being they’re stupid, they’re just not as interesting as you are (especially if you’re reading this, you’re almost certainly in the top quartile. Even if you don’t think it, you probably are: you’re reading a blog for Christ’s sake. Most people don’t even know what a blog is.)

A colleague of mine has to give a presentation about a Corporate iPhone AppStore that we’re building. Half way through, he realised the audience weren’t feeling it, and so said, “Who here knows what an appstore is?”. About four people their hands up.

It’s back to this thing about making basic applications. Almost no one cares about fancy features. It’s why the iPad and iPhone have taken off, even though they have the computing capacity of my eight year old laptop. Get the key basics right – the things people are actually interested in – and you’ve got them. And get those bits sorted before you start adding all sorts of new features that no one wants.

Pretty Basic (21/03/2012)

An application I built at work has been rolled out to a group of pilot test users.

One of the first pieces of feedback that came back was:

“It’s pretty basic but it does what I need”

I have to admit, I took this as a massive compliment.

I designed the application to fix a massive problem that’s been dragging on for about 10 years. It’s been given a grade 1 audit severity report. People have tried and failed to fix it many times before (there was once a manual process – the instructions were 20 pages long). People have argued, meetings have been had. I’ve been in meetings with 30 or 40 people about these issues.

The application itself came out of a number of meetings I had with senior technologists, who had no idea how to fix the problem.

The fact that someone can look at the solution and say, “m’eh, it’s pretty basic” is really a sign of a good solution, I think.

Obviously, part of my plan was to simplify the process as much as possible (in fact, as a result of his feedback, someone gave me an idea which meant I could remove one of the drop down options from the form). It’s a real case of the Unix Philosophy in action:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

In actual fact, it even handles text streams as well!

I’m reminded again of the importance of simplicity in application development. In fact, the application replaces some scripts that I wrote. That turned out to be too intricate complex. They were longer, more involved, relied more on their input being in the right format. At the time I thought they were the neatest solution, but I was wrong. They weren’t simple enough.

How you achieve simplicity in a complex world where people complicate things all the time is a difficult question. All you can do is practice it at all times, and try to get more and more experienced at developing “simple” applications. 

Keeping on Top of Things (16/02/2012)

In many ways my last few days have been filled with thoughts about scope creep. As I said a little while ago, a lot of my projects are suffering from this. And partly it’s because I’m being a little bit too ambitious. So I’ve intentionally dialled back on what I’m doing to make sure I hit the core values.

Part of this has involved reviewing my coding, and I’ve reminded myself of the importance of building a central, maintainable framework.

“Maintainable” is the key word here because “code rots”:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

You realise this when you come back to something you were working on several months ago, try to run it and it crashes.

  • Partly it’s because of that bug that you never got round to fixing but knew about and knew the workaround for.
  • Partly it’s because something else changed along the way and broke it.
  • Partly it’s because you’re not caring for it and fixing bugs and improving it any more.

As soon as you stop actively looking after it, it starts getting worse.

Of course, you can’t look after every project at once, but what you can do is write a centralised code library, look after that, and pull much of your stuff from that. That way, you’re actively looking after most of the code at once.

Jeff calls this “tending to your software garden” and I think I agree with him. I think I need to come up with more ways to keep my garden well looked after.

At Least the Directories are Active (30/01/2012)

I may be struggling with my house situation, but life trundles onto.

I’ve been building my web application at work, which I’ve really been enjoying doing. It’s great to be totally in control of a project and just fix it however you like.

However, I’m writing it in ASP.Net, which is a language I don’t really know that well.

Today I a discovery. If the DNS is set up correctly, you can get the asset number of the machine that’s connecting to the webpage.

Assetnumber = System.Net.Dns.GetHostEntry(Request.ServerVariables(“REMOTE_ADDR”)).HostName

This is brilliant. It’s something I didn’t think you could do. But the header data contains the IP address, and if you do a Reverse DNS lookup, you can get the asset number.

Of course, it’s the full domain name, so you have to trim a bit off the end, but that’s easy:

Assetnumber = UCASE(LEFT(Assetnumber,INSTR(Assetnumber,”.”)-1))

Once you can do this, the possibilities are quite exciting. It means you know who the user is, and what computer they’re on, so you can really tailor the results back to them.

Never underestimate (25/01/2012)

There’s a couple of projects I’ve been working on that I thought were going to be really easy and were actually incredibly difficult. I’ve realised, there are so often so many unforseen circumstances.

I’ve realised that even though I’d read Jeff’s article on estimating before, I’m still rubbish at estimating how long things will take:

When you compare the original single-point estimates to the Best Case and Worst Case estimates, you see that the 11.25 total of the single-point estimates is much closer to the Best Case estimate of 10.5 days than to the Worst Case total of 18.25 days.

You’ll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate. Thinking through the worst case result can sometimes expose additional work that must be done even in the best case, which can raise the nominal estimate. In thinking through the worst case, I like to ask developers how long the task would take if everything went wrong. People’s worst case estimates are often optimistic worst cases rather than true worst cases.

I need to start doing this in my projects, and, also, asking other people to do this as well.

I had to get angry with our outsourced IT partner this week as they came to a meeting having not done the one thing I asked them to do. I think I got the balance right – calm but very displeased. So we’ll see if they do it again.

Afterwards, they were so eager to please me that they said they’d get the next bit of work done within a week. I probably should have pushed more for best case/worst case estimates.

Taking Shortcuts (20/01/2012)

I was fiddling around in Notepad2 today and I needed to comment out a bunch of lines (to see the effect without them).

It turns out there’s a keyboard shortcut for this:

Control + Q

And this seems to be a standard. By chance, I was working in Notepad++ this afternoon and it worked there too. Another one to file away in the memory

Tag Cloud