One of the challenges that comes with managing any software project is making sure that milestones and deliverables are handled on time. The thing is, it’s hard – from the project outset – to always to predict some of the things that will crop up within each milestone.

If you’re using source control, this can make it difficult to keep your source control in sync with what milestone on which you’re working.

For example, I typically like to work on a milestone, then tag it, and release it. After that, I may do something like `milestone-1.1` or `milestone-1.2` as changes arise, but the more work that arises with each future milestone, and the various impacts it has on previous milestones, the more difficult it can be to truly track each milestone.

So what are we to do?

Continue reading

Generally speaking, the majority of the work that I do with third party APIs is done so in the context of WordPress, but the truth is that what I’m about to say is subject to whatever platform you’re work with – be it .NET, Rails, COBOL, or whatever you or your dad maybe using :).

But a feature in Standard recently quit working because of an underlying change in a third party API. Now, to our credit, we normally do a good job with following blogs and release notes when an API is going to change.

In this case, there was no documentation on any of this – something just stopped working, so we needed to dig in and fix it. The fix is under testing and will be released later, but the point that I’m trying to make is that there is always a danger in working with third party APIs.

Continue reading