Marco Valtas

Not every company will embrace new technologies or methodologies, but you probably will be in charge to achieve a similar performance as companies that adopt new technologies and methodologies such as Scrum and Rails. So, what you should know to get things done in a agile way but without a formal agile method inside your company? Here's some things that can save your time and health.

Know what is: Paradox of Choice

Users are not evil or dumb, they are humans. And humans who knows the problem you want to solve, even if they are evil or dumb, that's a fact. If you have to deal with users try to not block your mind to their presence, they have the key of your success. If you block them, then you have a good chance to deliver something that would not solve their problem. Software is all about users, right?

When talking to users always, I mean always, be aware of the Paradox of Choice. In companies that use the old "Get all requirements -> Some stuff -> Put in production" flux, you probably will ask if the user want this or that, and as influenced by the Paradox of Choice he or she will want all you offer and more. You know were this ends, in a big multi-function software that forgets to solve the main problem in a good way.

Know this: If you can't model you can't build it.

This quote is from John Walker, and you should be aware of that. You should know ways to model your problem in a more formal way, maybe using UML. The main thing here is to abstract a little before code anything, some simple diagrams can save your life, you can avoid wrong architectural choices if you draw your idea in a paper before start coding or writing a specification.

You don't have to master UML or Canonical Abstract Prototyping , but you have to know the enough to represent your mind outside it. This helps to organize your thought and maybe linguistic determinism plays a hole in here. The constrains of a UML could save you from some traps, as the diagram gets confuse and clouded maybe you have to think a little more about the problem.

Know this trap: Analysis Paralysis

When you have too much worries in modeling you can be bitten by the "Analysis Paralysis" anti-pattern. As I said before you should model, modeling is good, modeling too much not. Some insecurity about the project can make you afraid to deliver your specifications until they are perfect. But what you have to keep in mind is that there's no such thing as a perfect specification. In fact I think that "specification" is not a good name because it's more like technical guidelines than a complete solution.

"Working Software Is Your Primary Goal", Scott W. Ambler wrote in "Agile Modeling". That's it. If you try to model, or specify a perfect document you got it wrong, your final product is not a model. Note that a abstraction cannot be in same details of what is abstracted, if so, there's no abstraction at all. Experience will teach what is a good enough model.

Know what is: The KISS principle

Keep It Simple, Stupid. Some problems are complex, but shouldn't make them more complex. When trying to solve a problem try to be simple about it. In software you can design a solution that will take hundreds of lines of code, a bunch of classes and maybe solve the problem, that can be a problem. Software has this "soft" nature and people think if the goal is achieved then the solution is right, not quite.

I remember in my Linear Algebra course in college when we got the right answers by the wrong methods the professor marked the question as wrong. "You answered right but you solved it wrong." that's harsh, but true. When you try to solve a problem think carefully how you are solving it, getting the right answer is not a indication that you solved it right. (see this too)

Occams Razor is a good way to think about simple solutions, if is getting too complex, if the code start to smell, think about it again. I'm not saying that every problem has a simple solution, but when getting a to complex solution, make a review to be sure that your path is the more simple, even if it's a complex path.

Know the: Scrum's and XP's principles

As the introduction of this article said you can't use Scrum or XP in your company, but this is not excuse to not know Scrums and XP's principles and foundations. Scrum and XP are methodologies that try to solve common problems in software development and some principles are applicable even if you can't use it explicitly. Like the Scrum sprint, we can't ask the user to always refine priorities, but we can try to deliver a functional piece of the software every week or so. User stories of XP is a good way to organize requirements. Using some of the concepts and knowing the problems they try to solve can help you and your team to reach better results.

Know what is: Function Point Analysis

Function Point Analysis (FPA) it's a metric for software. FPA is hard to do, takes time and if is not a procedure in your company you probably wont be granted the time to do it. But there's something about FPA that is very useful, the "User Perspective". FPA is all about how the user sees the system, every function the system is capable to do and the your knows about is subject to count. The key thing is, if the user asks for a "sort by name" in a column this will affect the complexity of your project.

So, before you say "yes" to something that seems simple, remember that even a little "sort by" adds cost to your project. You can make your user aware of this and construct a good relationship before start to promise things that you can't deliver. When you use FPA you get a notion of the impact of "little" things added, so even if you can't use a formal FPA approach try to make a little informal count (but don't cheat in the count) to see more clearly how "little" functions scale to big efforts.

Really know about: Human-Computer Interaction

That's tricky, but users need help to choose a interface that suits them. I've seem developers leave at the user the responsibility to transform a complex spreadsheet system in a new interface for the web, the "draw what you want" approach. Worse, one developer just copied the spreadsheet interface to a web interface. That's not the way to do it. Users are not aware of the possibilities of a alternative interface, and the developer who copy a interface probably is not helping the user at all, sometimes the propose of a new system is to avoid spreadsheet interface in the first place.

User generally has a idea of what he/she wants of the interface, some want fast input, some fast search, some want most info in one screen and others want a step by step, like wizards, to complete a process. When you get this information you can draw screens that help the user but, do not let the user freely draw the screen, use a guideline to help you and the user, like Apple Human Interface Guidelines. Is not that you should write Apple like softwares but when you are familiar with some of the concepts, you get a better idea if a interface will work or not. Who never designed a interface which users keep making the same mistakes over and over again can throw the first stone. When this happens is a wrong designed interface not a dumb user.

If your users can't use your software you are doomed, doesn't matter if you have the finest code that a programmer can ever produce. You be in a sad place where your users keep using a software that you think is a crap and not using your new top designed solution. Usability is something you should worry about, not knowing could kill your project.

That's it