Saturday, 31 March 2018

Planning

Even though I’ve read plenty of great books centered around Agile, eXtreme Programming, etc. over the years, it’s always been difficult to view them as anything other than idealized pie-in-the-sky philosophies… something used at some magical startups or whatever, but not really anything us ‘mere mortal’ developers would ever get involved with. Even when I talk with developers at companies who publicly declare themselves as using Scrum, Agile, etc., a lot of the time the people down in the trenches mention it being a bit different…

Lately I’ve been learning a lot more about Scrum. Not so much because Scrum is inherently better than Agile… more like that’s what some projects in VSTS were already using as a template, so I figured that I had might as well make another attempt at delving into the details on it.

As much as I had expected early on to find a reason to dismiss it, there’s actually a lot in it that I love. Using the sprints to make minimum-viable products at a fairly predictable cadence sounds awesome to me and many of the features in VSTS make that very easy to do.

I was kind of surprised that the default Scrum template didn’t have a field for how long a task took (or even how long you thought it would take…) and just had a field for how much work remains. That was a bit odd. I’m a MASSIVE fan of Joel Spolsky in general, but I especially liked a post he did over a decade ago called Evidence Based Scheduling. (If you aren’t familiar with it, check it out!) While I don’t even want to consider how much time I’d need to spend on creating a similar Monte Carlo simulator for possible ship dates based on historical velocities, I do see value in tracking that information for if/when I’m ever actually able to do that sort of analysis…

I don’t work on any projects right now that actively adhere to Scrum, so a lot of this still feels a bit academic… but I think any changes I’m able to implement within existing projects that can benefit from a Scrum-like or Scrum-ish approach, it’s at least a step in the right direction. And, maybe one day I’ll get certified as a Scrum Master (though, to be honest, it strikes me a bit too much ‘fluff’ for something I’d be into).

Monday, 12 February 2018

Problem For Future Me

There’s an episode of The Simpsons where Homer is being lectured about regrets he will have later down the road. Homer responds with, “That’s a problem for future Homer. Man, I don’t envy that guy!

As odd at it may sound, I’ve found that to be a rather liberating perspective at times.

Rather than getting bogged down with analysis-paralysis, unknown-unknowns, and trying to plan every last detail before moving forward, sometimes it’s actually a lot more effective to just start moving forward and deal with those pesky ‘implementation details’ later…

Aside from occasionally needing to adjust my approach as I go, nothing is a better motivator than knowing the point of no return is long gone and just needing reach the goal…

It’s a very Zen experience — accepting the present moment’s situation and working with the current tools and knowledge available to move forward.

Maybe I just have a high risk-tolerance level, but it seems to work for me!

Monday, 29 January 2018

Break ALL THE THINGS!

Over the years, I’ve really developed a love for breaking stuff…

Whether it’s a code review or blackbox testing of a third-party application, I go into it expecting there to be problems… I might not always know where they are, but I am confident they exist.

In the world of infosec, the mantra is “assume breach”. Well, I apply a similar mindset to testing — “assume bug”.

If all of the tests are pretty green “PASS” messages, I assume it’s only because the tests aren’t extensive enough or missed some edge-case scenario.

I’ll do some more posts in the future about it, but I’m going to start playing with some different testing harnesses and frameworks in the upcoming months and try to see how much I can get out of them. Until then, though, I guess I’ll just stick with my manual testing.

Sunday, 31 December 2017

2017.Dispose();

Another year over… and a new one on the way…

This year I was able to take a more active lead in the hiring process — everything from creating a job description from scratch all the way to creating and implementing interview questions and tests. It was a lot of fun.

There was more C# development this year, but still quite a lot of work being done in VB.NET. I’m at the point where I don’t have a huge concern whether I’m working on VB.NET or C#. It’s not the language that makes the code good or bad. I’m generally happy just as long as things seem understandable, maintainable, and don’t have the stink of being a rushed hack just to get stuff out the door.

In the upcoming year, I’d like to get more involved in the local dev community. I used to go to the various SQL Saturday events and stuff, but kind of got burnt out on them. I found a pretty nice Tampa development group on Slack that does local meetups, so I might give that a try. Always good to have others available to bounce ideas off of, swap stories with, etc.

See ya’ll in 2018!

Monday, 27 November 2017

Screeps

It’s no secret that I dislike working with JavaScript. Maybe I’ve just grown accustomed to strong-typed languages with great tools for static analysis. Plenty of my bad experiences with JS were the result of bugs/typos I introduced and not a direct fault of the language, but many of them could’ve been caught ahead of time…

All of that being said, I’ve actually enjoyed playing Screeps. Basically, it’s a massive multiplayer online game where you program (using JavaScript, TypeScript, or other transpiled languages) how your objects in the game will behave. It’s a bit like an ever nerdier version of Minecraft :)

It hasn’t made me love programming in JS but it has at least kept me from being annoyed about it… I’m too busy solving (in-game) problems to dwell much on the language… which is probably a good thing…