drawing of computer program

An approach to problem solving with computer programs

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books.

In this day and age the situation is very different. There are countless resources where you can see how people approach problem solving using computer programs. You can watch live streams of people working on popular Open Source projects or watch tutorial videos. They all give good insight into the process of coding and shows how you can reason about issues you encounter. One thing you don’t get to see in these rehearsed videos is how they come up with the solutions and how they learned to solve it. In short, you don’t get to see their frantic googling, pulling of hair and general frustration which is usually involved. You don’t see the chat messages discussing topics and expressions of doubts about the solutions.

What I’m getting at, is that there are some things related to problem solving with computer programs which we don’t discuss that often and which is not shown in most coding videos. I will try to outline my preferred way of approaching a problem in an attempt to show that even though I have done this for a living in almost two decades, my approach is not one linear process where I know the steps nor the place I want to end up.

Make it visual

Regardless of wether it is coding up an UI component or creating an API endpoint to solve a data access issue, I have to make it visual. What I mean by that is that I got to draw something somewhere. It could be doodling something on a piece of paper, drawing on a white-board or putting some boxes’n things in a Google slide. This visual I try to update as learn more about the problem I’m trying to solve. More often than not I have to start over. Usually my first assumptions where wrong. That is not a problem! It means I’ve learned something and it’s better to “scrap” a drawing or slide than to revert code changes deployed in production. 

I have met programmers who are able to process things like this in their head. They are able to find design flaws etc by visualising what happens it in their head. This is something I struggle with. I can perhaps “run” a couple of steps of a process in my head, but then I loose it. My short term memory is terrible and I’m also not that great at keeping focus when thinking. Therefor I commit my thoughts to paper or some digital tool. One nice side effect of this is that documentation comes pretty easy, as I’ve been doing that throughout the problem solving process. 

The format in which I draw or the tool I use does not matter, it’s proximity and flexibility that matters. I find modelling tools constraining rather than helpful and enabling. Therefor I tend to use generic tools for visualising / drawing / doodling. There are formal approaches on how to modell software processes and create designs. Personally I find just “drawing whatever” is more useful then ensuring it is 100% correct UML syntax. I am not saying you should not seek learning techniques for modelling software. Everything you can learn which can be added to your toolbox is always worth checking out.

Large problems only? 

My process is the same for wether I’m trying to create some distributed architecture or if it is creating a small UI component. Once the issue requires me to think more than a couple of steps ahead, this is my go to approach and it is something I feel comfortable with. I find that there is no problem too small where this does not help. Sometimes my head just isn’t in it and doing some simple drawings works wonders for me.

Solving the problem

Once the design and preparation is done it is time to solve it. I use similar approach when it comes to writing the code for solving the problem. You can visualise the problem to solve with a drawing, but you can also visualise the flow of a program using text. I learned this approach reading the book Code Complete by Steve McConnel. He said that before writing actual programming statements, you can flesh out the details just using code comments. 

someFunction () {

  // if there is an item
    // render delete button
    // if not render the add button
  
    // write the label of the item
  // then add a parenthesis and a number

}

Once you have got some thing written down, read it back and see if it still makes sense. You should refactor the code block until it makes sense and it does what you meant it to. Perhaps you should extract a method or maybe you need to call out to a service and retrieve some more data. Refactoring when all you have is code comments is easy. As opposed fixing written and deployed code. I’m not saying this is something you must do, it is just one approach which I find helpful at times. 

There are other techniques, such as test driven development, which serves the same purpose as writing code comments before coding (I am aware there are more advantages, but this is not the topic of this post). Others use pseudocode to achieve the same thing (check out Thomas’ post on the topic  “I love pseudocode”). Learning multiple ways to solve problems is useful and something that will be beneficial regardless of the technological platform you happen to be working with.

“Kids, stay in school”

This article contains methods which happen to work well for me. Others will have different approaches and techniques. What is important is staying open minded and stay curious. To keep learning is essential to having a long career as a programmer. 

Quote

Software development as a cooperative game

http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development

This quote got me thinking today, because if it really is a cooperative game and teams are how we structure people working to solve problems, shouldn’t we look towards other team activities for inspiration?

When you work as a team, it is important to have diversity and a mixed set of skills. Especially in software development cross-functional teams is something that can be a good thing. Now, I have worked on many such teams and I’ve interacted with even more. One thing that comes to mind is that many teams miss some of the key success criteria for teams in sports: trust and the focus on making others better.

Making others better

The last point is something which was a corner stone of Norwegian soccer coach legend Nils Arne Eggen. His philosophy on how to make a team of mediocer players perform better than teams with way better players was to have a focus on making sure everyone wanted to make their team mates better. Playing a pass that puts your team mate into trouble is not good. It prevents you from making a mistake, but putting the other guy in trouble is bad for the team.

In geek-culture we always strive for the next thing. Wether it is a new tool, metholdogy or technology. Regardless of what has been don previously, we always want to opt for something else the next time we do something. This of course is fun and everyone wants to be working with “the next thing”. It’ll allow you for a small period of time, until someone else has “the next thing”, to keep your head up high and look at all the grunts who work with “what we used to do”. Our continued strive for the next thing is of course a good thing, however it can also be harmfull. Especially in a collaborative game setting, where you want to make others better. Pushing ahead with “the next thing” leaving everyone else behind is not making your team mates better. What would be better is to push for “the next thing” while making sure everyone else can cath up with you. Naturally, this approach doesn’t come with as much personal glory or will make you look better then everyone else. However it will make everyone you collaborate with better. I believe that we can strive towards focusing more on making those arround us better. I also believe that this way of thinking is good for business. What good is one amazing team, when you have six others who are just lagging behind?

Of course, I realize that my opinions are a result of my upbringing in socialist Norway and that this way of thinking is perhaps very weird for some of you.

Trust

Trust is another thing that so many teams, especially in Norway (having worked mostly in Norway I can’t really tell if it is better or worse elsewhere), lack. You can see this lack of trust manifest itself in numerous ways. Micro-management is the legendary sign of a lack of trust in team members. A lesser known one is a team where every decission must be made when everyone agreees. This “democracy” is really just a front for a total lack of trust in each other. When a team consists of memeber who don’t trust each others abilities the democratic way of making decissions ensures that there is a sense of control (which of course is true, because in such team nothing really happens).

Cross-functional teams paired with a “flat hierarchy” is of course the worst kind of team where trust is just not in play at all. Using the “flat hierarchy” as an exscuse for micro-management is a classic. The director of what-ever-the-fuck needs to make decisssions on color. Or manager of God-known-what needs to be in place for user testing. All discuised as managers “contributing” and being “hands-on”, when it really is just good old fashioned micro-management applied because of a total lack of trust in the teams abilities to make good good work.

In closing..

What was the executive summary of this rant-post? It is that we are terrible at team work and most software development teams lack what great teams of other disicplines have. We need to broaden our horizon and look outside our fucked up industry to see how we should collaborate on achieving greatness

A collaborative game?

image Photo by Michael Heiss

A popular mantra the past few years is that “software is a collaborative game”. However in a large organization or project, is this really possible?

When things get big and the number of communications lines exceed what is possible to handle for an individual, is it really possible to collaborate?

A behavior of teams when things get clouded is to construct a world which is tangible and possible to manage. They try to isolate themselves and put up mechanisms to detect breaches of their perimeter.

Architecture in such projects have a characteristic that there are numerous anti corruption layers all preventing a fail fast type approach. Each one added by the team which needs to have control over their domain. The result is that you get an architecture riddled with safety mechanisms you have a really hard time figuring out what went wrong when it does. Failing gracefully is good, but adding these mechanisms all over tour stack spells trouble.

There are of course other issues with teams moving into isolation. Collaboration with teams who’s main focus it to stay independent is challenging. How can you achieve a common understanding with protectionism as the strategy? Should you just accept the fact that teams need to isolate when things get complicated?

Optimizing the whole When everyone tries to create their own walled mansion with safe guards and security systems, how can you achieve a common way of doing things? Can you optimize the whole when everyone that would effect is only focused on their isolation? 

Tips og Triks Til Trivsel med Flex

Flex har virkelig begynt å få fotfeste i Norge det siste året. Dette merker man i jobbannonser hvor det stadig oftere er nevnet Flex kompetanse og man merker det med antallet hendvendelser som kommer angående hjelp til å begynne med Flex.

Å starte med Flex er ikke noe stort problem og de fleste utviklere klarer veldig lett å komme igang med å lage applikasjoner. Tilsvarende lett er det å gå i en del fallgruver og gjøre en del feil. Jeg har arbeidet med Flex en stund og har dermed også vært nedi de fleste fallgruvene. Derfor tenkte jeg å dele noen av mine beste tips og triks som jeg har lært meg til å bruke for å ennå raskere levere Flex applikasjoner.

  • Ha alltid en modell i bunnen også når du lager mockups og prototyper.
  • Data Driven Application Design: sørg for at det alltid er dataene som driver applikasjonen din ved hjelp av data binding
  • Les dokumentasjonen om klassen Binding Utils og sørg for å laste ned koden til Observere og ObervereValue.
  • Logging: lag deg en logger som gjør det mulig for andre brukere og sende deg logg når det oppstår feil situasjoner. Et slikt eksempel er en logger som bruke Firebug.
  • Evolutionary Application Architecture: ikke bygge rammeverk og komponenter i tilfelle du trenger de. Flex rammeverket gjør det veldig enkelt å gradvis bygge ut en prototype til en ferdig applikasjon. Lag for eksempel aldri en gjenbrukbar komponent før du faktisk skal bruke den for andre gang.

Mange av disse tingene vil du kanskje si at er vanlige regler for god systemutvikling, og det er selvsagt helt riktig. Likevel er det viktig å påpeke at disse tingene selvsagt også gjelder når man jobber med Flex. Det er veldig lett å tro at fordi det er en ny teknologi så gjør man ting anderledes. Å følge prinsippene i objekt orientert programmering (OOP) gjør det enklere å utvikler og vedlikeholde Flex applikasjoner også.

Test drevet Flex utvikling

Mange spør meg om hvordan kan man drive testdervet utvikling når man jobber med Flex. Svaret ligger i tipsene ovenfor, nemlig å ha en data drevet applikasjon hvor hendelser i grensesnittet gjøres gjennom å manipulere en modell klasse. Hvis du gjør dette gjennom å implementere presentation model mønsteret vil du merke at å jobbe test drevet ikke er noe problem i Flex.

Gjennom å ha en modell klasse som brukes til å manipulere data (og dermed også grensesnittet) kan du veldig enkelt skrive enhetstester for modell klassen. Dermed får du dokumentert oppførselen i applikasjonen gjennom testene samtidig som kvaliteten på koden din øker. Min gode venn Børre Wessel har holdt en presentasjon på Scotch On The Rock hvor han snakker om hvordan du implementerer presentation model mønsteret i Action Script.
Anbefalt lesning om testing av grensesnitt er artikkelserien til Adobe Consulting’s Paul Williams som tar for seg en lang rekke mønster som gjør testing av Flex applikasjoner enklere.