Skip to content

Posts tagged ‘programming’

Agile: The Most Overused Word in IT

A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?

Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.

At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.

The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?

My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.

Building A Platform – Farmville Should not Take Down Facebook

I am joining a project at work that will revamp our intranet architecture and allow us to continue to bring innovative and cutting edge capabilities to our workforce. One of the issues that we’ve seen over the past few years had been that rich applications that have integrated with our portal have been too tightly integrated. In several cases, they have the capability to hog resources or even take a server offline due to a catastrophic fault. This is one of the areas that we want to prevent in the future and are working with our partners to articulate this desire.

This week, one of those partners was in town to talk through our needs and the analogy I came up with was that “Farmville should not take down Facebook”. That is to say the Facebook is an application platform that provides base services (demographics, content, wall updates, etc) to applications that can then use them to do interesting* things. This is similar to a corporate intranet that knows who a user is, what permissions they have, and what their demographic information is and then exposes those to applications and portlets based on their permission. In my current environment, there are some of these constituent applications that use the same resource sets as the portal platform and thus, they could negatively impact the performance of the intranet. In V.Next this should not be the case.

*Pre-emptive snarky comment: I do not consider Farmville or any of those games to be “interesting things”. In fact, I’ve never played a Facebook game. It’s merely illustrative of the type of Platform as a Service (PaaS) model that we are striving for.

Instrumenting Applications

I was driving along the other day and my “Check Engine” light came on. This is an ominous occurrence because this light can be an indicator of a looming system failure within an automobile. The catalytic converter could be on its last legs (you won’t pass the emissions inspection), there could be an engine seal broken that is causing a loss of compression (or allowing something into the block), or any number of other things. In short – this light is worthless. It means you need to take it to a mechanic to read a code.

Why they couldn’t just add a little LED display onto the dash panel to help me out, I have no idea. Maybe there are a bunch of System.out statements that would generate so much noise you’d be confused. This is exactly what happens in software development. As people debug problems in their code, they implement statements to help them track the flow (this is especially true for web apps when you can’t monitor server processes). With a little bit of care, these messages can implemented as part of a framework – Log4net, for example. If you think through “what can go wrong in this section” and “what would I like to know to diagnose it” or “what conditions indicate something bad is going to happen” you can more thoughtfully instrument your code. Adding monitors on top of this implementation to alert on particular messages or conditions then becomes a trivial task. Unfortunately, all too often useless messages get generated in a non-managed way and the signal to noise ratio become unbearably small. 

As for my “check engine” light? Apparently on a cold morning when I filled up my gas tank, I didn’t turn the gas cap until it clicked 3 times. There was nothing wrong with my engine. Here’s how I imagine that poorly written code block looks:

try{

   MonitorFuelSystem()

}catch(GasCapException e){

    System.out.println(“Ignore this exception”);

}

 

Thanks for turning the light on and freaking me out over nothing.

 

Design Debate of the Day


MARTIN COOPER – Inventor of the Mobile Phone
Originally uploaded by Mark Berry – Photographer & Graphic Designer

Over the past several years, mobile computing has exploded on palm sized devices. The most obvious of these is the iPhone, but numerous other providers (HTC, Motorola, etc) are hot on the trail as Google and Microsoft also provide app stores. For individual developers, the choice of platform is usually a personal decision and one that is clear cut. For the enterprise developer, this choice is usually dictated by external factors as well as management.

In sizing the requests for next year’s initiatives, there was a separate project request to enable mobile access to some core resources on our intranet. Mind you, there are some heavy initiatives that will be changing the information architecture of the site, as well as potentially the content management system. When you are making those kinds of changes, it would be nice to design in mobility from the start.

My dilemma is this – it is more expensive to design in mobility considerations than to ignore them completely. Produce too high of a price tag and the project won’t make it past the budget review (or will get slashed in the process). With the separate mobility project, I have to make assumptions about the current state of the platform – so I have to pretend that I didn’t size in mobility considerations into the other request.

Whatever the case, I will have to design for mobility regardless on whether that particular feature gets funded. That’s just the right way to do it in my mind. You can only go into Best Buy and look at those fancy High Definition television sets for so long until you bring it into your house. And if you aren’t set up with the baseline infrastructure to support it (HD programming, HDMI cables, mounting hardware, etc) it will end up costing you considerably more than the price tag on the TV indicated.

Privacy Threats Are Abound

Facebook quizzes seem relatively harmless. But a recent app the ACLU put together as a quiz demonstrates the amount of information you make available when you take the quiz to find out what Wizard of Oz character you are. The article cited below notes that “Once details about your personal life are collected by a quiz developer, who knows where they could end up or how they could be used. Shared? Sold? Turned over to the government?”

While these questions may seem alarmist, the report certainly sheds light on exactly what is private on Facebook – really nothing. You may think you are only sharing photos and information with your friends, but the reality is that you shouldn’t put anything on Facebook that you do not want shared with the entire world.

Read More -> Facebook knows too much, ACLU says in warning of quizzes

  • Recent Tweets…