07 Jun

Presentation on Unit Testing Inertia

I gave a talk on Tuesday at the Las Vegas PHP Meetup Group titled Unit Testing Inertia.

The basis of the talk was getting over the inertia in writing tests in either a pre-existing application or just getting started writing unit tests in general. It went over very well with a good question and answer session afterwards. While I didn’t spend as much time prepping for this talk, I was comfortable enough with the material (and helped there was no code involved) that it was a solid presentation.

The short summary of the talk is for every new method/bug-fix/feature written, write a test for something else at the same time, and start with the stuff that is easier to test.

I’ve been going through a few different pieces of software for writing and displaying my presentations and this is the first time I’ve been really happy with the tool-chain. I used Deckset, which is a Markdown based presentation system with some great looking styles.

Humorous aside, my spelling is atrocious and even though I had to type out “inertia” dozens of times I misspelled it every time and even just now writing this up, I misspelled it every time.

03 Nov

GMane.Comp.Version-Control.Git – Linus Torvalds on C and C++

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don’t talk about portability,
> it’s BS.

*YOU* are full of bullshit.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

via GMane.Comp.Version-Control.Git – Linus Torvalds on C and C++. Programmers are an opinionated bunch.

27 Sep

Vivek Haldar – Size is the best predictor of code quality

A long paper trail of software engineering studies has shown that many internal code metrics (such as methods per class, depth of inheritance tree, coupling among classes etc.) are correlated with external attributes, the most important of which is bugs. What the authors of this paper show is that when they introduce a second variable, namely, the total size of the program, into the statistical analysis and control for it, the correlation between all these code metrics and bugs disappears.

via Vivek Haldar – Size is the best predictor of code quality. Essentially length of code tied with code metrics becomes a reasonable predictor of bugs.

28 Jun

Utoxin’s Random Insanity – CakePHP + Symlinks = Pain

Now that I’ve had a day or so to recover, I’m going to tell you about what I just spent 2-3 weeks trying to resolve. By way of explanation, our main product at work is a CakePHP based CMS application. It has a lot of neat features, including the ability for users to upgrade to newer versions any time they choose. We keep all versions present in /etc/precious_core/<version_number>/, and each user has a symlink to the relevant directory in their webroot.

When they upgrade, part of the process is to replace that symlink with a new on that points at their new version. For a long time we’ve known there was a problem of some kind related to CakePHP’s cache that developed after upgrades, but it was never a huge problem, so we mostly just ignored it. However, in a recent release, it started causing major problems, and I got tasked with finding and fixing the actual bug. I figured it would take a day or two, and I’d be done with it. Little did I know just how painful this was going to be.

I initially tried several ways of forcing the cache to get cleared when the app was upgraded. That worked well, as far as it went, but then a new problem surfaced. At least half the time, the cache would re-populate with bad data after an upgrade. Some of the cached file paths would be for the wrong version of the central app, for no apparent reason. I tried throwing even more thorough cache clearing at it. Things got a little better, but it still wasn’t working.

Finally, I fully duplicated our production setup on my local dev machine, parallel version directories included, and installed a PHP debugger, so I could step through the code and figure out what exactly was going on.

via Utoxin’s Random Insanity – CakePHP + Symlinks = Pain. Debugging oh what a joy it is.

28 Jun

Pastebin.com – Ok, I came up with an example. Programming is like doing a massive sudoku.

Ok, I came up with an example.

Programming is like doing a massive sudoku. But you’re not just doing you’re own square, you have to line up the edges with squares that you’ve already done, or squares other people in your team are working on.

And it’s not just squares that you’ve done, you have to anticipate the sudoku’s you’ll be doing days, weeks or months from now, and leave easy numbers at the edges so it isn’t impossible to do those squares.

And that’s why some programmers are so engrossed in it, and get all worked up, because they’re like "You left a 5 in the middle of the square, what kind of asshole does that, now I’m gonna have to line all my square up with that".

And then someone points out a bug, an you have to trace it back to the square it came from, and then redo that square without screwing up all the other ones.

And after a few hours of that, you either surf facebook and go on IM, or you start growing a beard and forgetting to wash and getting weirdly obsessed with star wars, and people look at you weird and they’re like why do you care about it so much, and through the bleary screen-burnt eyes of your insanity you reply "The squares, can’t you see, the squares, they’re so beautiful"

And that’s why programmers don’t get invited to parties.

What was your question again?

via Pastebin.com – Ok, I came up with an example. Programming is like doing a massive sudoku.. Just a little to close to home.

22 Jun

GitHub – Announcing GitHub for Mac

Pull requests, merge button, fork queue, issues, pages, wiki –– all awesome features that make sharing easier. But those things are only great after you’ve pushed your code to GitHub.

Today we’re happy to announce GitHub for Mac.

via GitHub – Announcing GitHub for Mac. It’s very nice looking and does a fair bit of abstraction towards the intricacy of dealing with Git on a daily basis. Should be an awesome tool for people who need to use a version control system but aren’t sure how to use Git. GitHub for Mac also uses the wonderful open source project Chamelon, which lets you build an app that targets the Mac and iOS devices with the same code base.

24 Feb

BBC News – Microsoft says phone update failed 1 in 10 users

Microsoft has revealed that 1 in 10 users who tried to install a software update on their Windows mobile experienced problems.

The company had previously said that only a "small number" of handsets were affected.

Owners have reported a range of issues following the download, from phones crashing, to becoming completely unusable.

Microsoft pulled the update soon after the problem came to light.

via BBC News – Microsoft says phone update failed 1 in 10 users. That’s pretty poor.

01 Feb

The Broadcast Tower – Your code should be as boring as possible

In short, interesting code is often the sign of hack, and it’s up to you to figure out whether the hack is a clever or useless one. And just because the code is boring doesn’t mean it’s not hiding hidden problems. But I still find myself surprisingly pleased with a nice, boring code review.

via The Broadcast Tower – Your code should be as boring as possible. Shockingly enough makes a far amount of sense.

22 Jan

Rands In Repose – Managing Nerds

In front of you is The Problem. While I don’t know what The Problem is, I do know that you have a bright team of talented nerds working for you, and I know that you don’t have a clue how to tackle The Problem: you need the nerds and you don’t know where to start. The Problem is unique in that your normal leadership moves aren’t going to work. You can already predict the collective nerd reaction and it’s the opposite of what you need to happen.

Rather than attacking this Problem directly, let’s turn it around and explore the inner workings of your nerd’s mental landscape for inspired next steps.

via Rands In Repose – Managing Nerds. How does one go about managing nerds.

01 Aug

Review/Summary of The Mythical Man Month

The Mythical Man Month is one of those seminal works of software engineering that praise is heaped upon and quoted at most if not all software firms. The book itself is perhaps most famous for popularizing the rule that “adding more programmers to a late project makes it even later”. This however is not the only conclusion to be gathered from this book.

The Summary

The book should perhaps be most praised for being written in a manner that the engineer in me can get behind. Short and fast chapters with not a lot of fuss of double telling a point after it has been made. Including a bullet point review of the book, it is a short 300ish pages long. Perhaps the largest complaint of the book is that the focus of the book is upon system or what is now known as embedded programming. That being said there are a great many points to be gathered from the book.

The first is that there are several different types of programs, simply a program, a programming system, a programming product and finally a programming system product. Only the last is one that is the goal of most programming teams. The first is essentially something that the programmer can use and build in the course of a few days or weeks of effort. The second and third are required intermediaries to the fourth but moving in opposite directions. A programming system is where a program becomes a part of a larger project. This requires the program to mandate all input and output to be semantically valid and correct, to be on a well-defined budget of resources (be they computer time/memory and i-o limitations) and to play well with other program.

The programming product requires a vast suite of test cases so that other programmers may rely upon it and through documentation so that others may extend it’s feature set. Each of these two intermediary steps requires in the authors words “three times the cost of the earlier one”, so that together the programming system product “costs nine times as much”.

Still inside of the first chapter, do we get the next great revelation; programming is a fun and abstract art. This leads to its own set of problems, least of which is the abstract part. Perhaps the greatest of these is the requirement of perfection demanded from computers. The list of problems quickly grows in the next few paragraphs, being at the whim of others decisions and others goals, depending upon others perfection for a programmer rarely works alone in all aspects of a project, the design is more fun that actual implementation, debugging becomes more difficult the further one goes, and finally that rarely does it seem to be ahead of the curve more often than not it feels that the project is already obsolete before completion.

I love the image that the author weaves here of Software Engineering being a tar pit and him trying to “lay some boardwalks across the tar”.

Scheduling software is a notoriously dark art. The author brings forth a simple and basic rule for dividing up the time on a software project.

  • 1/3 Planning
  • 1/6 Coding
  • 1/4 Component and early system test
  • 1/4 Systems test, all components in hand

The next bit is the most famous of the conclusions from the book in which the author discusses how adding more people to a project doesn’t make it any sooner to completion, if anything slows down the project overall. There is the matter of both training these new engineers on the inner workings of the project before they can even be brought into working on the project on anything approaching a full-time basis, the next is that as you add more people there develop more lines of communication and more time to delegate and split tasks into manageable pieces for each person to work on. Essentially far easier for two people to meet and decide on two parts of the project to tackle, far harder for three, four or five people to meet and delegate the project into x number of pieces for each to work. Especially for the task to be divided in such a way that you are both accounting for one’s abilities and trying to time the project so each finishes at roughly the same time.

The author coming from the discussion of how more people on a project leads to an overall slowdown in the project argues with more data than any other section for a “surgical team” to tackle projects, even those ridiculously large ones to be split into manageable portions for surgical teams to take on as opposed to “hog-butchering team”. Essentially for a coordinated effort by one or two programmers with all others acting in support of those one or two programmers.

The vast majority of the rest of the book espouses and stresses these points in some way or another. From espousing that a good design (note design here terms of design of the architecture not design in look and feel) can only come from a single or extremely limited number of persons. That architects of systems of a system have a tendency to over design to achieve complete interoperability and extensibility. Assigning value to both the number of bytes and time needed for a function to complete is a good way to limit over design.

There must be both formal and informal level design documentation. Intercommunication and organization are requirements for even a decent project to take flight not just among team members but across all teams. The author argues for daily meetings for all team members with weekly inter-team meetings. He also argues for some form of a project workbook to collect all changes and thoughts of the team members so that anyone reviewing or testing a section has complete access to all knowledge of that section on the spot. At the same time the author argues for all team members being required to see and read the workbook, at a later date he becomes convinced otherwise and instead stresses that the information be made available but not in essence required reading. Plan for throwing away an initial version of the project. Iterate quickly on a project, create a working version as quickly as possible and keep up it’s working state throughout the course of the project. A project does not all of sudden become late but rather over the course of one piece taking longer or one day of missed meetings.

Documentation while hated is a really important feature for a good project, not just for the customer but for programmers to know the why behind a piece of code. Re-using or purchasing that which has previously been done to save lots of time and effort than in effect re-creating the wheel. Adding functionality to software in a piece-meal fashion, rather than all at once.

It’s all in all a long list of points for such a short book and perhaps most interesting for being such an old book espouses some ideas that I would have thought not in practice until much later.

The Review

Overall wonderful to read, super fast and easy to read. Lots of examples and data points from basic research to analogues and one-off stories to provide force behind each point. The majority of the points I would take little to no time to critique except for that it focuses heavily on systems programming and hence not in an area that I find myself (and probably most modern programmers) working in. Little effort to none is made for focusing on the actual usability of a project beyond that of other programmers, whereas most Software Engineers find themselves writing code that a normal human being will interact and deal with. The book also develops a ten person strong team with just one or two people actually devoted to writing code. This seems more than a bit of overkill. I would suggest something much closer to the 37Signals plan, one manager, two programmers, one designer and one tester. Perhaps my smallest critiques is the focus on “man” hours as opposed to person hours, also the little one off here and there of using a religious idea as proof for a software engineering plan. For instance, in the bullet points on using two core programmers on a team the author makes a footnote of “Note God’s plan for marriage”. Minor annoyances I admit but they detract from an other wise well written and developed ideas.

I would recommend this book to not just Managers of software projects but also to the programmers under their leadership in the hope that they understand better the difficulty in creating an outstanding “programming system project” and quite possibly how to build a better maintainable project.