Six bad habits of programmers

Here are six things that many programmers do, but are a waste of time or plain counterproductive.

First, programmers say yes to impossible time schedules. I've done it myself too many times. Stop doing that and take some pride in your work, please.

Second, programmers follow so called "Best Practices". There are no best practices! However there may exist pretty good solutions to certain development challenges. But please make sure you actually have the problem before applying the solution. Remember that no solution is free.

Third, programmers love Inversion of Control. There is too much effort being wasted trying to decouple everything today. It will just make your code harder to read. And however easy it may seem to adjust your code for IoC containers, it is still extra work. Suddenly you cannot use a function you need without making sure that your class is known by and created by the IoC container. Extra work, and for what? Simpler testing? Do you even write tests? You certainly don't need IoC for writing tests.

Fourth, programmers write Service-Oriented code. What happened to Object Orientation? Remember the programming style where the programmer's knowledge is built-into the code itself? The data knows what methods are applicable. Why would you tear that apart and go back to procedural style programming where the data knows nothing of the functions? Waste!

Fifth, programmers use separate build systems. The IDE is there for you to use. It knows how to build your applications. It helps you set everything up, from source code location, library and dependency management, to deployment. Use it, use your IDE! Then use a build server that supports your IDE. Why should I use a separate system for doing all that, where I need to set everything up one more time, without the support of an interactive helpful tool? Ok, there is a reason: The current crop of IDEs are not good enough at dependency management, and the build servers don't support the IDE project formats well enough. Our world is moving to slowly. The tool makers need to speed up improvements.

Sixth, programmers access databases with ORM frameworks. And you need to access the db. You want some help CRUDing your data. Who doesn't. Let's use a great ORM framework. No, no, no! If you want to be able to change things, update your domain classes and keep improving your system you must stop, stop, stop using relational databases. The relational database is a dictator that owns the schema. Your code also wants to own the schema, the classes. The db and the code fight to rule the domain and both lose. That setup aint DRY. The code needs to own the schema/classes. You need to go NoSQL, and you need a db access framework that helps reading persisted data in older formats.

Enhanced syntax for switch statements (and if statements)

The switch statement syntax has always bothered me since it introduces two levels of indentation:

   switch (value)
   {
      case 0:
      case 1:
         doThis();
         break;
      case 2:
      case 3:
         doThat();
         break;
      default:
         doSomethingElse();
   }

Of course one could reduce the indentation. It would look a bit unusual but it could work:

   switch (value) {
   case 0:
   case 1:
      doThis();
      break;
   case 2:
   case 3:
      doThat();
      break;
   default:
      doSomethingElse();
   }

Let's instead write this with an if statement. It is, arguably, easier to read:

   if (value == 0 || value == 1)
      doThis();
   else if (value == 2 || value == 3)
      doThat();
   else
      doSomethingElse();

Even with curly brackets the if statement kind of looks cleaner than the switch statement:

   if (value == 0 || value == 1)
   {
      doThis();
   }
   else if (value == 2 || value == 3)
   {
      doThat();
   }
   else
   {
      doSomethingElse();

   }

But let's think about it for a while. Let's be creative. We could make an enhanced switch statement:

   switch (value) case (0, 1)
      doThis();
   case (2, 3)
      doThat();
   default:
      doSomethingElse();

The enhanced switch statement looks a whole lot like an if statement. How about we enhance the if statement instead:

   if (value == 0, 1)
      doThis();
   else if (2, 3)
      doThat();
   else
      doSomethingElse();

Hey, this looks good! I wonder if it would be possible to write an IntelliJ plugin (or ReSharper plugin) for this kind of syntax enhancement? I guess I gotta find out.

First impressions of Visual Studio 2012 by an IntelliJ user

I'm back with Visual Studio which I haven't used since before the first version of .Net. I've been told VS12 is a great IDE, better than Xcode, Eclipse and even IntelliJ. These are my first impressions of "vanilla" Visual Studio, i.e. before installing ReSharper. Let's start with the good stuff. 

Note to self: Need to update this to VS13 now that I've installed it.

Nice features of VS12

• VS builds on Visual Basic's ground breaking GUI builder. Delphi also had a great GUI builder (at least back in the days when I used it). Add a button, double-click, write code. This is something to dream about in Xcode.
• The built-in webserver makes it easy to get going with MVC development. (In Java one would typically install Tomcat and then set it up within IntelliJ as an application server).
• Page Inspector is an enhanced browser whose Inspect function will take you directly to the code that created the inspected part of the page.

And that's it. I'm done with the nice features. Now it's time for features that are...

Great Tools (photo by OZinOH)

Missing in VS12

• There is no keyboard shortcut for Get Latest Version (Recursive). Unless of course you think pressing the following sequence of keys is an actual shortcut: Alt+V, P, Home, Menu, L.
• And when you manage to get latest, there is no simple path to go the Changeset Details window. Viewing the latest changes is an important operation that should be part of Get Latest Version.
• There is no keyboard shortcut for Compare with previous version. Also you cannot make one yourself since the api call is different for different windows, or even missing.
• Call Hiearchy stops on interface methods. Hey, those get called too you know!  R# 
• You can't create filterable todo categories. I will often use my own todo tag/token for stuff I need to implement, test or check later. I don't want to mix those todos with those of other team members.  R# 
• Code Snippets are good, but where's the editor?  R# 
• There is no Find Usages function. Yes, there is the Find Symbols (Shift+F12) but the result view has a bad layout showing the complete file path on every row. Also Find Symbols doesn't handle usages of the property name that exposes a member variable.  R# 
• There is no syntax hightlighing for member variables.

Bad and/or Weird Stuff

• The Options window contains hundreds of options but it isn't resizable! It stays small, showing only a few options at a time.  VS13 
• You can't edit code without stopping execution (Break All). That would seem like logical restriction, but what about adding a comment - not possible! Also, Break All will navigate away from the source file where you wanted to make the edit, and take you the place where execution is taking place. Annoying.
• Many common operations have double-stroke keyboard shortcuts, e.g. Show the solution explorer, Format document, and Show quick info.
• The Find in files result window is badly formatted. For example, it shows the entire JQuery source code if a match is found within it.
• View Call Hierarchy shortcut (Ctrl+K, Ctrl+T) doesn't work at all.
• What is source code doing in the project root folder? It is a really weird thing to mix source files and other project files. Bad design choice.

Conclusion

I can't live without ReSharper.

JavaScript global variable declaration tidbits

To make a global variable in JavaScript, type:

var thisHereThing = {};

You could make it even simpler:

thisHereThing = {};

They are the same thing (pretty much).


Let's try a practical example, a namespace for your app:

var TC =  TC || {};

Of course you may simplify it to:

TC =  TC || {};

Ouch! No, it doesn't work. What is going on here?

What happens is this. The js runtime tries to evaluate the right hand side of the equals sign. It finds a non-existing variable, TC, and gives up. But then, why does it work in the first example that starts with var? It turns out var statements get interpreted before the normal program flow. When the evalution of the right hand side takes place, the TC variable already exists and has an Undefined value.

Even the following piece of code won't throw an exception, even though b is used before its declaration.

var a = b;
var b;

If you wanted to skip the var keyword there still is a way to do that:

TC = window.TC || {};

Global variables are properties of the window object. And properties get created when they are used. So that works as well.

Learning and using JavaScript feels like exploring uncharted territories a lot more than using Java or C# does. Sometimes I like exploring.

Learning from my work notes

As I read through my work notes from last week, I made a few interesting conclusions. As a little background I'm working on integrating a web based system and an access control smartcard system. To bridge the gap between web software and the smartcard reader hardware I'm using an old-style ActiveX component. The component is controlled via Javascript that also communicates with the server.

Week 16 Work Notes

Tuesday Apr 16

• Testing ajax calls. Adding error handling when json parsing fails, or if there is a server exception, or an Ajax timeout.
• Starting to work on the "activate card" function in js.
• Adding a progress indicator to show we're in the middle of a ajax and/or cardreader operation.
• Thinking through how to handle the removal of a card when we're in the middle of a transaction.

Wednesday Apr 17

• Refactoring out all ajax calls into its own js-class.
• Fixing progress indicator (which stackoverflowed in IE8)
• Learning more about ActiveX exception handling when called from js.

Thursday Apr 18

• Now catching and handling all js exception with window.onerror.
• More testing of error and exception handling.
• Adding error handling for when card is removed during transaction.
• Testing and fixing validation of input fields.
• Fixing ajax timeout error handling.
• Thinking through card validity dates, and when a card is to be considered expired or empty.

Friday Apr 19

• Formatting of date and time. Trying to replicate what goes on in Java.
• Coding empty card recognition. Discover that a null end date means the card never expires. Have to change my if statements accordingly.
• The name field from the card is full of \0000. Clean!
• Enable/disable code for input fields is all wrong. Refactoring to methods into one that handles all cases.

32 hours

Summed up, I spent 32 hours working on the following:

• UI: Error handling and input validation (Ajax, ActiveX, card data)
• UI: Progress indicator
• UI: Enabling/disabling of input fields depending on state
• UI: Datetime formatting
• Business code: Recognizing empty card put onto reader

Conclusion #1

I spent almost all time dealing with user interaction issues. Did I have to spend so much time with error handling and GUI stuff? I guess not. I could have skipped a lot of the error handling code and testing I wrote. I could have skipped the progress indicator. I could have trusted the user not to click buttons at the wrong moments. Basically I could have saved a lot of time.

But I didn't. Why? Because otherwise I would have ended up with a really low quality application. Software quality is all about user experience. This is conclusion #1:

• You need to pay attention to detail and invest a lot of time into UX if you want to build high quality software that makes users productive (and happy?).

Conclusions #2 and #3

What if I were to estimate the time required for the tasks I completed during those four work days? Well, actually all of the tasks are sub tasks to just one user story:

•  Activate Card: Make it possible to activate a new card and write name, access list, validity dates and amount to it.

In reality I estimated a bigger load of work that just this story, but what if I had estimated just this one story? How much extra time would I have added for the error handling and ux stuff? Maybe a work day, 8 hours. Why such a discrepancy to the outcome? I think for two reasons, conclusions #2 and #3:

• No matter how much work experince you have it is just darn difficult to understand how many small tasks are needed to get a story done.
• Your boss is not going to like it when you add four days to the schedule for just "error handling". And he's going to get the answer he wants.

That's all for now. :-)

Whats wrong with IoC and Spring?

My main concern with Spring and the Inversion of Control paradigm is that it encourages the separation of data from operations on the data. In the typical Spring project model classes carry the data and service classes contain operations on that data. So what's wrong with that? It breaks the best feature of Object Oriented software dev, the fact that the data "knows" what operations are available. As an IDE user you just need to press the magical dot which will give you a menu of methods to call. That is great because the knowledge of the programmer that created the class is now built-into the class itself. When the methods are moved into a separate service class the magical dot does not work any more. That is a big deal.

Does it have to be like this with IoC and Spring? I don't know yet. Since it's more or less impossible for an indenpendant Java consultant to avoid projects that uses Spring I'm reading Spring in Action. I've already read quite a bit on IoC but I thought I'd better learn some more practical struff. I will probably get back to this topic in the future.

Om konsultmäklare, konsultbolag och konsultsäljare

Jag som konsult är alltid ute efter ett spännande uppdrag där jag kan skapa mycket nytta och glädje för andra människor. När ett behov som matchar min kompetens uppstår vill jag maximera mina chanser att få uppdraget. Drömläget är att jag känner projektledaren och vi har jobbat tillsammans tidigare; saken är redan klar!

Om så inte är fallet behöver jag en bro mellan mig och konsultköparen. Som frilansare är jag fri att välja den säljare ( =eventuellt ett helt team med olika roller) som jag tror mest på. Dom bästa möjligheterna att få uppdraget får jag om säljaren känner både konsultköparen och mig personligen. På så sätt kan det bildas en stark bro av förtroende som kan leda till en affär.

Spana in konsultsäljaren längst upp på taket

Vanliga konsultbolag har en fördel gentemot mäklare: Säljarna har lättare att bygga en relation till sin konsult. Mäklarens stall är mer flyktigt och kräver en större insats att hålla koll på. Å andra sidan säljer konsultbolaget (nästan) bara sina egna konsulter. Mäklaren däremot har tillgång till alla frilansare och mindre konsultbolag.

Vad gäller relationen mellan säljare och konsult finns det olika grader av kompetensbedömning som mäklaren gör. Det finns mäklare som investerar mycket lite tid att värdera konsulten dom offererar. Kanske funkar deras affärsidé ändå pga en hög volym av potentiella uppdrag och många offereringar? Dessa mäklare hamnar såklart längst ner på listan för mig som konsult. Jag vill säljas som "filmstjärnan" och inte som en "statist". Faktum är att den säljare som mekaniskt matchar uppdragsbeskrivningar med konsultprofiler kan ersättas av.... en app!

Det finns även ett fall då även den bästa konsultsäljaren kan ersättas av en app, och det är när det finns så få tillgängliga konsulter som kan göra jobbet att köparen hinner intervjua allihop själv. Jag tror det finns en stor potential för kompetensrekryteringsmarknaden att effektiveras. För konsultköparnas skull hoppas jag också att dom snart upptäcker den där appen. I mitt tidigare inlägg broderar jag ut lite mer om denna (web-)app som jag där kallar LinkedIn för konsulter.

WyWallet har potential att lyckas

Jag har länge kliat mig i skallen och undrat varför kreditkort är det enda betalsystem som funkar förutom kontanter, både IRL och på nätet. Och med fungerar menar jag: Att systemet erbjuds som betalalternativ tillräckligt ofta för att man orkar bry sig om att skaffa konto. Men äntligen verkar det vara en ny guldrush mot nya (mikro-)betalsystem. Bankerna kommer med Swish. Teleoperatörerna har lanserat WyWallet. Förutom att kunna göra egna inköp är  jag är nyfiken på om något av dessa system kan vara en bra betalsystem för Sprend.

Idag har jag provkört WyWallet och det har inte varit lätt att göra. Det finns nämligen ingenstans man kan handla med sitt WyWallet-konto! Jo okej, sms-betalningar dras automatiskt från WyWallet-kontot i stället för mobilfakturan. WyWallet lovar att det så småningom också skall bli möjligt att betala i webbutiker, i mobil-appar och i fysiska affärer - med det går inte ännu. Därför har jag bara kunna provköra dom delar av appen som inte har med betalning att göra.

Slutsatsen av app-testet är att fyra stora rika teleoperatörer måste kunna mycket mycket bättre än så här. iPhone-appen är ett riktigt buggigt budget-bygge:

• Appen kraschar gång på gång. Det händer speciellt ofta när man återvänder till appen efter en stund i en annan app.
• Appen är slö som tusan. Det tar flera sekunder att växla mellan sidorna, vilket leder till feltryckningar.
• Den ser inte ut som en iOS-app; jag gissar den är byggd i något crossplatform-verktyg.
• Dom få texter som finns är inte ens korrekturlästa.
• Vid påfyllning av kontot via kreditkort skickas man ut ur appen och in i Safari till ett flöde som inte är mobilanpassat.

På WyWallets facebooksida kan man hitta flera inlägg som undrar varför man ersätter ett fungerade system, sms, med ett sämre, WyWallet-kontot.  Ja vänta lite, vi har ju redan sms. Funkar inte det? Jag tror ändå en app kan göra inköp enklare, och det finns inget som är viktigare än just enkelhet enligt min ödmjuka mening. Om jag förstår flödet korrekt så handlar man genom att:

1. Ange sitt mobilnummer i ett webbformulär
2. Mobilen säger pling-plong: Vill du köpa <x> från <y> till priset <z> kr?
3. Du godkänner genom att knappa in din pinkod.

Är detta enklare än att knappa in ett nummer och en kod i sms-appen? Jag tror risken för misstag blir lägre i WyWallet-appen eftersom man redan kan sitt eget mobilnummer i huvudet (?), samt att WyWallet-appen anger vad man betalar för. Jag jag betalar via sms trippelcheckar jag alltid att numret och koden är rätt. Det skulle jag slippa med WyWallet.

Andra fördelar är en tydlig transaktionslista, och möjligheten att flytta pengar från mig till dig. Det kostar 1 kr vilket det definitivt är värt bara för att man kan spåra transaktionen.

En stor nackdel som även David Paulsson uppmärksammat är att det blir klurigt att betala med företagspengar. Varför kan man inte registera två konton i WyWallet-appen, ett privatkonto samt ett för företaget? När man genomför ett köp skulle man enkelt kunna välja vilket konto som köpet skall registreras på. Vid slutet av månaden skulle företaget man jobbar för få en komplett lista på alla inköp som gjorts. Ingen extra adminstration eller pappershantering. Lösningen som WyWallet erbjuder är att man loggar på sitt konto och väljer ut företagsinköpen, laddar ner en pdf som man sedan skickar till sin arbetsgivare för bokföring. Funkar, men är onödigt krångligt.

Jag tror WyWallet har en stor potential. Tjänsten har fördel gentemot Swish eftersom sms-betalningar redan är ett etablerat system. Kvaliteten måste dock höjas över hela linjen (PS. Jag är bra på att koda).

LinkedIn för konsulter

Jag fick nyligen en fråga i en LinkedIn-grupp vad jag saknade som frilansare på LinkedIn. Detta ämne har jag haft i tankarna under en längre tid. Här är mitt svar.


"Det som mest saknas [på LinkedIn] är möjligheten att ange följande egenskaper:

1. Jag söker uppdrag (inte anställning)
2. Jag ledig fr.o.m. detta datum
3. Jag passar i fler än en roll. Konsultuppdragsprofiler är ofta nischade mot en viss roll. En person har ofta kompetens för flera roller.

Det viktiga är att egenskaperna är sökbara vilket skulle ge konsultköparen kommandot över rekryteringsprocessen.

Av olika skäl är konsultbranschen, även inom IT, synnerligen analog. Personliga kontakter är oerhörd viktiga, och det är gott så. Men ofta kan kedjan mellan projektledare till potentiell projektmedlem vara för lång. En tjänst, kanske LinkedIn, kanske en helt ny tjänst, skulle i vissa fall kunna kapa dessa led.

För att exemplifiera, säg att jag är projektledare för ett nytt projekt. Jag letar efter en  kompetent medarbetare som är a) ledig vid projektstart 2012-11-15, b) finns i Norrköping, c) är en skicklig yrkesman inom området mjukvarutest. Tänk nu om den sökningen ger vid handen att det finns tre stycken som matchar. Dessa tre kan jag ta in och intervjua själv.

Säg att det blir 30 träffar i stället. Då kan jag behöva hjälp och vänder mig till konsultföretag och mäklare som jag har förtroende för. Deras jobb blir att sovra och hitta de bästa. Kanske skickar jag med en länk till sökningen jag gjort i min förfrågan.

Kanske ser jag att konsultbolaget X har ett flertal passande kandidater direkt i min sökning. Lika bra att vända mig till dom direkt. Samma sak för konsultmäklare; mäklaren har ett stall med konsulter precis som ett konsultbolag med anställda.

LinkedIn skulle kunna bli tjänsten som digitaliserar den konservativa konsultbranschen. Det skulle också kunna vara en helt ny tjänst med fokus på konsulting och inte rekrytering som bröt ny mark."

The App Director

The App Director Arne Evertsson behind the Java compiler (?)

“Yeah, let’s make a movie!”

På svenska

A film producer is the project manager of a movie production. He makes sure there is a script and financing. He finds the right people for the different creative and practical tasks involved in a movie making project. Also, he supports the director who is responsible for the artistic aspects of the film.

Artistic aspects? Sounds like painting or sculpture. The director carves away on a statue that is supposed to bring about emotions, thoughts and hopefully convey an important message. Script, actors and all sorts of skilled people make up the tools and materials used by the director.

My impression is that the director points and leads, and then stands back to let each person perform her particular skills. The producer is always there, providing a shoulder to cry on (?).

So what does this have to do with application development? Let's look at the contemporary de-facto standard for software development, the project method Scrum.


Scrum?

The developers, the scrum master and the product owner are the protagonists in a Scrum project. We will take a closer look at the product owner. The main task of the product owner is to feed the team with a prioritized list of stuff to do. The developers starts at the top and work their way down the list. The product owner moves, adds, or deletes tasks from the list. Each task is described in terms of business value rather than technical or solution aspects.

The above is a very sound way to go about software development, and it is the foundation on which all Agile methods stand. There are however a bunch of questions that are not answered by Scrum, important questions where development teams often fly blind.

Before the team can get started on a task it needs be sufficiently well-defined: The story must be backlog-ready, i.e. the task must be ready for the todo list. What does that mean? It’s not obvious. This question is also related to another question: When is the interaction design performed? Is the design of the user interface a prerequisite to get started or is it performed at the same time as, or even after, the programming? Also not very clear.

Job ads for software projects will often list roles like business analyst, requirements engineer, and functional architect. You’re supposed to lead workshops, write requirements specs and act like a bridge between business and technology. What? I lost myself there. Where did the product owner go? Is there a project manager around? Is requirements engineering the same as application design? The plot thickens...


George and Steven have the answer to the riddle

George and Steven. Who's who?

The best friends George Lucas and Steven Spielberg created the classical Indiana Jones movies. George is the producer. Steven is the director. What if George and Steve have understood what it takes to succeed with project work?

Let us marry the product owner of Scrum with the director from Hollywood. Let us call the baby The App Director. The first thing he does is to put an equal sign between business benefits and end-user benefits. If nobody goes to see the movie the film studio makes no money. If the end-user doesn’t benefit from using the application, the company will make no money. It’s really that simple: Business benefits = End-user benefits. This fact is often lost somewhere between the powerpoint presentations and project documents.

The director has the vision. The director has the ability to make that vision tangible in the project goal. The vision comes from a deep knowledge of the needs, but even more from the creative skill of being able to visualize the solution. The app director identifies the users' needs. The app director designs the application, thereby becoming the main stakeholder. He is the CID, the Chief Interaction Designer. The app director realizes the end-user benefits.

Hey, wait a minute. Rewind please. You will need a business expert to know the business needs. There’s your app director, right? Yes. But only if said business expert is also an expert at application design. If not, the business export may be provide support for the director, great support. Learning the business rules is a necessary and very interesting activity for the director.

Let’s go back the Bearded Brothers, how would they do this?

George and Steven have long before the start of the shooting worked on a script together with the script writer. There exists a very clear picture of what shall be achieved. No matter whether Steven wrote the script himself or not it will become his script in the creative process. Before shooting begins each scene is pinned to the wall in the of storyboards. Even as the shooting is in progress there are changes being made to the script.

Now re-read the previous paragraph substituting implementation for shooting, application design for script, interaction designer for script writer, story for scene, wireframes for storyboards.

Let’s leave George and Steven alone for a while.


I believe this is the way to do it

Before the team of developers gets going there is a design. It’s not complete, does not contain all the details, but it does provide a good picture of what we right now think is the end goal. There are of course details for the stories at the top of the list. The director works with an interaction team that contains interaction and graphic designers, and they will always stay ahead of the developer team. Before a a story/task is ready for the todo list, the director will get input from one or more developers regarding tech issues and time estimations. In this way the todo list will be fed with doable tasks. As soon as the stories get done by the D-team they fly back to the I-team for usability evaluation; the conclusions of which get fed back into the loop.

Luckily we can avoid the Hollywood movie production monster machine. We are developers and we move with agility. The agile way is the basis for how we work.

I haven’t said a lot about the Application Producer but I think this role is more similar to the role of the Project Manager. Perhaps I would take a few Scrum master tasks and give them to the producer. The producer, together with the director, will be responsible for the delivery of a usable system with real benefits for the end-user.


Conclusions

I have four points to make:

1. Focus on end-user benefits and you will create business benefits.
2. Interaction design is the most powerful tool of the app director.
3. The app director is an expert at designing applications. Domain knowledge and business knowledge are input into the design process.
4. Use two teams, the interaction team and the developer team. The I-team always works ahead of, but also after, the U-team.

The application director is the product owner (Scrum) but with a clearer area of responsibility. He has a deep understanding of usability and user value. He transforms user needs into app design and leads the team all the way to the goal.

Applikationsregissören

“Ja, vi spelar in en film!”

In English

Applikationsregissör Arne Evertsson bakom Javakompilatorn (?)

En filmproducent har det övergripande ansvaret för att en film blir till. Det handlar om att se till att det finns ett manus, finansiering, och hitta rätt personer att utföra dom olika kreativa och praktiska uppgifterna i ett filmprojekt. Inte minst skall producenten stöda regissören som har det konstnärliga ansvaret för filmen.

Konstnärliga anvaret? Det låter som måleri eller skulptur. Regissören hackar fram en skulptur som skall väcka känslor, tankar och förhoppningsvis förmedla ett budskap. Materialet och verktygen utgörs av manus, skådisar och alla möjliga superproffs inom sina konstnärliga hantverksområden.

Mitt intryck är att regissören både pekar och leder men sedan också håller sig undan så att var och en kan bidra med sitt kunnande. Producenten finns alltid där som en axel att gråta emot (?).

Men vad har allt detta med applikationsutveckling att göra? Låt oss titta på samtidens defacto-standard vad gäller mjukvaruutveckling, projektmetodiken Scrum.

Scrum?

Utvecklarna, scrummästaren och produktägaren har huvudrollerna i ett Scrumprojekt. Låt oss titta närmare på produktägaren. Produktägarens huvuduppgift är att kontinuerligt föda teamet med en prioriterad lista av uppgifter. Utvecklarna betar av listan från toppen. Produktägaren stuvar om, lägger till eller tar bort från listan allt efter behov. Varje punkt i listan är beskriven i termer av affärsnytta, inte teknik eller tillvägagångssätt.

Detta är en mycket sund inställning till programutveckling, och arbetssättet är grunden för alla agila metoder, inte bara Scrum. Det finns dock ett antal frågor som inte besvaras av Scrum alls, viktiga frågor där utvecklingsteam ofta famlar i blindo.

Innan en uppgift kan påbörjas måste den vara tillräckligt väldefinierad så att teamet kan ta sig an den: Storyn skall vara backlog-ready. Det vill säga, uppgiften skall vara mogen att hamna på att-göra-listan. Vad betyder det? Oklart. Denna fråga är också relaterad till en annan: När sker interaktionsdesignen? Är användargränssnittets utformning en förutsättning för att påbörja utvecklingen eller sker detta samtidigt eller till och med senare? Också oklart.

I jobbannonser för mjukvaruprojekt används ofta rollbeskrivningar som business analyst, kravfångare, och verksamhetsanalytiker. Man skall hålla workshops, skriva kravspecifikationer och vara bryggan mellan verksamhet och teknik. Men det är ändå beställaren och styrgruppen som beslutar om projektets mål och innehåll. What? Jag tappade tråden där. Vart tog produktägaren vägen? Finns någon projektledare inblandad här? Är kravprioritering detsamma som applikationsdesign? The plot thickens...

George och Steven har svaret på gåtan

George och Steven. Eller kanske tvärtom?

Dom goaste vännerna George Lucas och Steven Spielberg ligger bakom dom klassiska filmerna om Indiana Jones. George är producenten. Steven är regissören. Tänk om det är så att George och Steven har fattat det där med att arbeta i projektform?

Låt oss gifta ihop produktägaren från Scrum med regissören från filmproduktion. Låt oss kalla bebisen för Applikationsregissör. Det första applikationsregissören gör är att sätta likamedtecken mellan affärsnytta och användarnytta. Om ingen tittar på filmen kommer filmbolaget inte att tjäna några pengar. Om inte användaren har nytta av applikationen kommer företaget inte att tjäna några pengar. Så enkelt är det faktiskt: Affärsnytta = Användarnytta. Detta är ett faktum som ofta försvinner bland powerpointpresentationer och projektdokument.

Regissören har visionen. Regissören har förmågan att konkretisera visionen i projektmålet. Visionen kommer från en djup kunskap om behovet, men i ännu högre grad från den kreativa förmågan att se lösningen framför sig. Applikationsregissören är behovsfångaren. Applikationsregissören designar applikationen och blir därmed kravställaren. Han är CID, Chief Interaction Designer. Applikationsregissören realiserar användarnyttan.

Men vänta lite nu. Spola tillbaka. Det måste ju till en verksamhetsexpert för att kunna se verksamhetens behov. Där har du din applikationsregissör. Eller hur? Ja. Men bara om nämnde verksamhetsexpert också är expert på applikationsdesign. Om inte, kan verksamhetsexperten vara ett stöd för applikationsregissören, ett fantastiskt bra stöd. Inhämtandet av verksamhetskunskap är en nödvändig och synnerligen intressant uppgift för regissören.

För att återknyta till bröderna Skägg, hur gör dom nu det här?

George och Steven har långt innan inspelningen jobbat på ett manus tillsammans med manusförfattaren. Det finns en väldigt tydlig bild av vad som skall åstadkommas. Oberoende om Steven skrivit manuset på egen hand eller ej så blir manuset hans egendom i den kreativa processen. Innan inspelningen startar sätter man upp varje scen på väggen i form av storyboards. Bara för att inspelningen har kommit igång är inte manuset gjutet i sten, utan ändringar och tillägg görs löpande under produktionen.

Läs nu om ovanstående stycke, men byt ut inspelningen mot implementationen, manuset mot applikationsdesignen, manusförfattaren mot interaktionsdesignern, scen mot story, storyboards mot wireframes.

Okej, låt oss lämna George och Steven för en stund.

Så här tror jag man skall göra

Innan teamet med programmerare sätter igång finns en design. Den är inte komplett, innehåller inte alla detaljer, men den ger en utmärkt bild av vad vi föreställer oss är slutmålet just nu. Detaljer finns däremot för dom stories som är högst på priolistan. Regissören jobbar alltså med ett interaktionsteam som innehåller interaktionsdesigner och grafisk formgivare, och dom ligger ständigt före utvecklingsteamet. Innan en story/uppgift är färdig för priolistan låter regissören också en eller flera utvecklare göra en teknisk design och uppskatting av omfattningen. På detta sätt föds priolistan med konkreta genomförbara uppgifter. Allt eftersom stories blir färdigprogrammerade åker dom tillbaka till interaktionsteamet som evaluerar användbarheten och tar med sig slutsatserna i det fortsatta arbetet.

Som tur är slipper vi den Hollywoodska massiva monstermaskinen som en filminspelning är. Vi systemutvecklare kan vara mycket mer lättrörliga. Den chansen försitter vi inte utan det agila tankesättet är grunden för hur vi jobbar.

Jag har inte sagt så mycket om Applikationsproducenten men denna roll liknar nog mer det som kallas Projektledare. Kanske stoppar man in en del av vad Scrummästaren gör i producentens arbetsuppgifter också. Tillsammans med applikationsregissören har han ansvar för att användarna får glädje och nytta av systemet.

Slutsatser

Det är fyra saker jag vill säga:

1. Fokusera på användarnytta och du kommer att skapa affärsnytta.
2. Interaktionsdesign är applikationsregissörens främsta verktyg.
3. Applikationsregissören är expert på att designa applikationer. Domänkunskap och verksamhetskunskap är input till designprocessen.
4. Jobba med två team, interaktionsteamet och utvecklingsteamet. I-teamet ligger ständigt före, men även efter, u-teamet.

Applikationsregissören är alltså en produktägare a la Scrum fast med ett tydligare mandat och arbetsuppgifter. Han har en djup förståelse för användbarhet och användarnytta. I hans huvud förvandlas behov till en konkret design och han leder teamet hela vägen in i mål.