Changes to Facebook API

Today we had something interesting happen at work.  We had just implemented some Facebook functionality on a project that was ready for release, and just before it was signed off today, a final end to end test was completed.  Part of that test was to test some functionality with social networks.  When the Facebook functionality was tested, it failed.

The functionality was meant to pre-populate the message box with a message that the user updated.  On Wednesday this was working, and today it wasn't.  Lets just say that this caused a few questions to be asked and a few worried people moving the corridors.  How can functionality that was working one day break the next when we made no changes to the code?  After some searching the web (Google is mostly always your friend), I found my answer.  Let me break it down for you.

Firstly, we were using the Javascript Library, specifically the FB.ui functionality. Using the Feed dialog box, we would place our user augmented message into the message box, which the user could then update and publish on their wall.  Now looking at the reference from the Facebook developers page (seen here http://developers.facebook.com/docs/reference/dialogs/feed/ ) the message property is what we used to pre-fill the dialog box. As you can see there is a note on the property that states that the field will be ignored on the 12th July, 2011.  So why was it still working two days ago (3/8 to be specific)?

Before I go into that let me first look at the policy for Apps in Facebook. If you go to the policy page (seen here http://developers.facebook.com/policy/ ) and read section 4 sub section 2 it states that an app will not pre-fill any fields.  (Then in the following sub section it states that the user can give permission for an app to post on their behalf. That is a task for next week.)

So back to the question, why did it just stop working?  If I were to guess, and that is all that I would be doing, I would say that Facebook just got fed up with people not looking at the policies and following them.  Apps should only pre fill the form when the user has done it some where else in the work flow.  I would say that there were plenty of apps that just didn't follow the rules and they just decided to enforce the rules.  And to be honest, I have no problem with them enforcing their policy.

Now, what is the lesson learned from all this?  Is it that we should not trust Facebook?  I would say not.  For me? The lesson is that when you are using third party services you need to be aware that what you don't control what happens with them.  You should intermittently test the services, just to make sure that they work as expected.  That is if you want to make sure that your sites and applications maintain the functionality that you build them with.
Hope this helps!

Agile vs Waterfall

Recently I found myself coding less and “planning” more. It took me a while to work out why, and when I did I thought I would write this so that others may avoid the trap I was in.

Firstly, some background. As you may or may not be aware, I am writing an API in java for read an OData source.  Now, I am using TDD principals to code the API (basically write a test case and then write the code that makes this test pass).  This means that I need to think in small increments, write a test for the small increment, then write a small increment that satisfies that test, then write another test for another small increment, then write that small increment and so on,  you get the idea.

Now back to the present.  I encountered the next part of my code requirements, implementing XML namespaces within my code.  This is where my problems started.  I did the right thing by researching some things on XML namespaces, to make sure that I understood how they were implemented and make sure my code didn’t vastly differ what it should be.  Then I did the wrong thing, I tried to plan the entire implementation of the XML Namespace component, rather than looking at the small piece I was dealing with (in this case pulling the namespace and storing it in the required format).

I was planning the reading dtd and metafiles and how that would work.  Looking at the manner that dtd’s could be delivered.  How would I know which was an internal namespace and which was an external? How would I register the external namespace in my code (for example the $metadata of an OData source)? And so on and so forth.  That is not how I am wanting to write my code.  I want to write a test for a small part, then write that small part.  In this case the small part was identifying the namespaces and putting them into a useful format.

This got me thinking about agile and waterfall practices.  Agile methodologies would say that you get the requirement and break it down into smaller pieces, and those into smaller pieces until you have something that can be done in a defined period of time (for example, in scrum you would break it down into smaller pieces that would be done within an iteration).  Whilst you know what the requirements are, you don’t design the entire solution for what may or may not happen, nor do you plan everything out at the start.  You break the requirement into smaller chunks and that into smaller chunks into a requirement that you can complete within a week or 2.

Waterfall is very different to this.  In the waterfall approach, you define every requirement that you can think of, plan the end result to the finest detail, then you start coding to the fine details that you have planned to deliver.  You don't start coding until you have the UX defined, the web services documented and the classes worked out and what each class properties and methods are.

Now, without going into a discussion about waterfall vs agile development practices, I will say my thoughts.  While there are parts of one in the other and vice versa, the two can not coexist.  For example, when your doing agile you need to know the end result, what is the stakeholder asking for.  That you can break down into smaller requirements and so on until it is small enough to complete in iteration or sprint.  And conversely in waterfall development, you can not say “deliver the whole project at once”, you need to break it down into smaller chunks that a developer can work on.

The main point of difference for me is that in my opinion, agile is about meeting the requirements that you have been asked to deliver.  No more no less.  You cant tell the stake holder what they want, you can only guide them along as you code and as they see the work.  This doesn't mean that if they say they want a field you don't do any error checking on it, or that you just make it work and not deliver a quality product.  What it does mean is that you don't enlarge the requirements to what you can see being needed down the track.  You meet the current need. If the database table needs a title, description and timestamp, don't add a link to a status that is then part of a different requirement.  By the same token you can guide the requirements along by asking questions like “where is this going to be reported?”, “Is there a need to report on this?”, “ Who should be able to edit this?”

Waterfall projects on the other hand you can vastly change the requirements because you are part of the planning process.  Nothing gets done until everything is defined and some form of specification documented.  You research to make sure that it is future proof, so that you can work on another project and this one wont need any attention.  You tend to guide the requirements and specifications, rather than the development.  But, once it is locked in, it takes a lot to change one line of the specifications that your working to.

Personally, I prefer agile development processes over waterfall process because you can be flexible, if you code something that the user changes their mind on you can adapt. (Hence, why it is called agile.)  You also only deliver what is needed, not what you think is best.  The issue with stakeholders is that they don’t always communicate it well to developers, project managers or product owners.  Hence the need to ask questions and listen to the answers.  You also end up with leaner code (it does what is needed, and nothing it doesn't) rather than bloated code with parts that are rarely, if ever, used.

Understanding

Understanding what you need to do before you start a project is important, but not understanding it all shouldn't stop a project starting. Most project work starts with a phrase like "wouldn't it be cool if we could....." or “I would like to be able to ... so that I can ..." I'll let you fill in the blanks.

This start leads into a review of what exactly is required, how it might work, and what the end user can expect when the project is complete. The more complete the review and requirements list is, the better for the understanding of the people working on the project. However, you can start the project even without this review being complete. I would say that it needs to be 60-70% complete, but at that point the project work can start.

Here is the catch; to start a project where the requirements are not complete invites a risk that you might need to redo parts as the requirements get more and more refined. If you’re willing to take that risk, then there is no problem. Just be prepared to make changes as the requirements change, or when new ones are added.

Why start when you might just need to redo it all? If it is done well, and you are able to mitigate the risk, you can deliver the completed project earlier than if you waited for the entire review to be completed. The risk could mean that it takes longer as you are always redoing the work to fit the latest requirements.