Wednesday, October 13

Why does agile need a label?

Scanned image of standard 3x5 notecard / index...Image via WikipediaScrum, LEAN, XP.... for many years people have attempted to apply these types of labels to the art of agile software development and delivery.  In fact, one could even go so far as to call the meta-label of "agile" in the same way.  Each of these communities have devoted followings of people who believe they have the best way to deliver software.  Can we just extract some practices and just call them good software development without the brand-able label, t-shirts, associated conferences, certifications, etc,etc?

The agile manifesto is so much simpler.  Value individuals and interactions, working software is the number one goal, customer collaboration and response to change.... these are the concepts that so eloquently described the essence of the movement.  Yet, it didn't take long for people to define what those meant in terms of processes with tools that helped implement the processes.  It didn't take long for people to start saying, "This is how agile will work, it can't work that way." or "You MUST have a stand up meeting" and "You must use story cards only on white 3x5 index cards that must be pinned, not stapled, glued, or otherwise fastened to a bulletin board with exposed cork only and no one can do anything if they aren't told to do so by the index card and if you use software that's a tool and that's not agile."

What we're missing here is that many of these practices were already being done in a somewhat disorganized way because they worked.  Having a colleague look at a problem with you was just called "helping" before it had the term "pair programming".  Talking to a customer to refine requirements during the development process was just being complete and paying attention to detail before it became a part of a process.

It would have been amazing to be in the room when the authors of the Agile Manifesto were defining these things, but they weren't discovering new territory.  They were defining and simplifying to the concepts that, in their experience, made the difference between successful and failed projects.  At least that's my impression of the Agile Manifesto having not actually been in the room. :)

Do what works.  If you want to label something as agile, that's it.  It means at the end of a period of time you have to spend some time evaluating if your choices worked or not, but it's a lot better than having people roll their eyes and perform a task because it's required of them, not because it does something valuable.
Enhanced by Zemanta

Saturday, October 9

A way for Linux to succeed as a gaming platform

If there's one thing where I have to concede the superiority of Windows to Linux, it is in the gaming world.  Not because DirectX is so much better than OpenGL or because the engines are better or anything fundamental to technology.  It's a 100% business decision, no one is willing to spend millions of extra dollars in game development, possibly to the detriment of gameplay, for the game to be cross-platform for the 1% of their population it will serve.  It's the same reason a lot of software and native hardware drivers are not available for Linux.  In most cases, the open source community writes the drivers they need for hardware and the projects are small enough that most hardware ends up getting support by people who need to do it in order to make their equipment work.  However, for large, complex software such as big title games, it's tough for open source developers to product equivalent products.  So for the most part, the gaming landscape for linux pretty much stinks.

There are a few major issues.  The number of different distributions is one of them.  With differences in dependencies and the fractured nature of the way linux is distributed, it is tough for a gaming vendor to predict all the different dependencies available to them.  There needs to be an abstraction layer that takes care of all this, but such an abstraction layer could definitely hinder performance.

Another issue is cohesiveness.  Just as there are lots of different dependencies on different distributions, there are lots of different choices as far as window and display managers.

There is, however, a way for Linux to succeed as a gaming platform and that's for hardware vendors like Nvidia and ATI to use the open source nature of Linux to their advantage and write their own "console" that runs on Linux.  They have already started doing this in a lot of the quick-boot media only distros that ship with some laptops.  You may be familiar with these if you have a computer where you can pop in a DVD and bring up a player without booting the entire operating system.  These players are often embedded into the chipsets and, more often than not, there's a Linux kernel running somewhere under the covers there.  Why not take that idea and give users a way to suspend their currently running session(regardless of hardware) to disk, and reboot their system in the "console" giving the user the opportunity to install and run gaming software titles.  This could work regardless of operating system, provide gaming vendors with the same consistency they now get with DirectX on Windows, give users nearly bare-metal performance since the system is devoting almost all its resources to the gaming environment with no interruption for overhead from OS services, and give all  users access to the full gambit of gaming titles regardless of operating system they are using.

I know what you're going to say, technically this is not gaming on Linux in the same way you may have thought about it previously.  But it is using the Linux kernel to provide a working system for a hardware vendor to work from that already provides a massive amount of hardware support, is low on resource consumption, inherently secure, and proven to work well in environments where optimum performance is a must.  It's already proven that it can work as a quick booting, media environment on numerous PCs, and everyone knows that the fact that it is open source means that game developers can optimize their code to the environment rather than having to guess at how Windows is doing something behind the scenes.