I recently was talking to some friends about the current state of browsers and operating systems and how the next year or two could really shake up what’s been traditionally considered the norm. You know, the IE sucks, Chrome is the fastest and most standard-compliant browser, OS X has the best usability and Windows is for the plebes mode of thinking that people have fallen into. It’s an easy mode to get used to, but that could be changing.
First, here’s some benchmarks from September 27th from Lifehacker. There’s an article about a very promising IE10, then there was a follow-up two days later about the upcoming Opera build.
As for Windows 8, here’s a good video from June demoing some features and the updated UI (the Internet’s Wadsworth Constant applies, so feel free to skip to 30% in).
Granted, until you use it yourself, it’s hard to say what the truth is when updates are announced. Personally, I thought the iPad UI seemed silly because it was just a spread out iPod/iPhone UI with wasted space, but using it is still really nice. So, we’ll see how things change.
When it comes to any one problem to solve, place to get to, goal to achieve, there are limitless ways to get there, especially when it comes to software. Those differences can be in technology used, development lifecycle, team size, test-driven, you name it, there’s a different way to do it.
One aspect, which is likely the most important aspect of them all, is your team’s structure and the different roles that people take and how those roles fit into getting things done well. Even when the team is really just one person, that one person has to take on those different roles. Though there are many different names for these roles, I’ll give them the most generic classifications possible and then give examples of those kind of roles and their relationship to the features or requirements needed for a project or effort.
Source – Examples: Client, Business Analyst
This is the person who has the inspiration or idea for what should be created and at least some vision of what that will look like. This could be a client who needs a website made, a developer with an idea for the next killer app or a business requirement coming from management. I tend to think of them as “the Source” because they are where the work or project is coming from.
Refiner – Examples: Project Manager, Lead Developer, Designer
Here we have the person who really delves into what needs to happen to make something useful and compelling. They either can be the Source who refines their own idea, or they could have a back-and-forth with the source to really find out what is going to happen, what’s needed and what benefit the idea is going to provide.
Architect – Examples: Technical Lead, Lead Developer
After the Source and Refiner have done their jobs and come up with what should be built, the Architect decides how it’s going to be built and how it’s going to happen. That can include deciding the technology or methodology that will make the idea into an actual project and how it’s going to be completed.
Builder – Examples: technical Lead, Developer
The Builder will take what the Architect, Refiner and Source have put together and make it a reality. They will take the project and actually build or complete it, likely with a fair amount of interaction with the above three as unforeseen or unplanned events, complications or considerations come into play.
Tester – Examples: End User, Project Manager, Client, Developer
Once the Builder believes they have finished creating the project, or at least portions of it, someone checks to make sure it’s behaving and works as expected. This Tester will often go back and forth with the Builder when unintended problems are found or missing features are discovered or additional requirements that weren’t thought of before are found.
User – Examples: General Public, Employee, Client
Finally, once the project has been completed, there is the actual user of that project. This is the person who the project was built for and who should be the main consideration throughout the project, making their life easier or more enriching in one way or another.
Now that we have these different roles defined, I hope to go into what an ideal structure would be on a given project in a follow-up post.
I’ve been thinking about PhoneGap and products similar to it that allow you to develop an application once and then deploy it across different environments. This way you can create one application using something like Sencha or jQTouch to get a really nice experience. Then you can release an Android app, a Blackberry app or an iOS app with relative ease without putting in the development effort required to create a variety of native apps.
That’s all old news and the debate is still raging about how to go about it and what tools to use and there are plenty of different, great arguments on both sides.
Then I thought about XBox, Playstation 3 and Wii.
Granted, I haven’t yet looked into the technical aspects of it, but being able to create a channel or app for each of those common consoles with a common codebase would be more than helpful for a variety of organizations. Whether you’re creating a small game that you want to run both on mobile and on those consoles without going through the process of distributing disks and working with publishers or you’re creating an application for an organization like the NFL, being able to roll out on all of those platforms relatively easily and at a lower cost to development would be an amazing asset.
This is just a thought experiment at this point, but it certainly makes me wonder about what could happen when you have that kind of cross platform development available.
