Category Archives: Software Development

The Bitcoin Currency Ecosystem

Business, Investing, Software Development April 2, 2013 Leave a comment

A much more general use of the word currency is anything that is used in any circumstances, as a medium of exchange. In this use, “currency” is a synonym for the concept of money.

This comes from Wikipedia’s definition of a currency and it fits to Bitcoin, which is where this post could end. But that would be a boring post and not help you much, so lets go a bit deeper. For a history lesson search for Crypto-Currency – Bitcoin and its mysterious inventor, a great article.

When Nic Brisbourne wrote about it in March, the total circulation of Bitcoin was $400m and as I write this it is well over a billion USD! More and more people want in and understand the nature of the system or at least trust it more. They are trusting into a currency, a means to exchange value, that is not connected to any state, that nobody controls, that is based on cryptography and code alone.

But VCs are starting to notice as visible in investments in Coinbase, Adam Drapers Bitcoin focus, as well as his father Tim Draper talking about it in a recent appearance on Stanford’s Entrepreneurial Thoughtleader Series.

Some argue that the Cyprus problem builds distrust in state controlled currencies and that is one of the reasons the current interest in Bitcoin is so high. It is inherently uncontrollable unless it is forbidden but you can’t just forbid a billion USD. But if you look at the Coinbase security procedure, it is that they only have a small % of bitcoins on their servers. The rest is backed up on thumb drives. What? Backed up currency? Yep, same as real bills, Bitcoins can actually be printed out on a slip of paper and put in a ring binder. You can even look into other people’s wallets if you know their wallet id. Here is one of mine for example, actually currently hosted on one of the many Bitcoin sites out there. This again means that you will want to have several wallets to not tell everyone who you exchange bitcoins with how much money you have.

But it brings us to an interesting piece with bitcoins. It is both very anonymous in that you can create a wallet and put bitcoins in there. If they come from another anonymous source, e.g. Cash or another anonymous Bitcoin address, then nobody knows whom that money belongs to, but they do know how much money is in the wallet if they know the wallet id. The big exchanges require you to authenticate yourself if you really want to deal in more than a few USD and they need to do that to loose the image of facilitating money laundry. This will be needed to build serious trust and build a stable currency that the nation stations cannot move against.

But can the current run up in value continue? My last transaction from some 14 days ago has gone up in value almost 100%. But even the geek in me couldn’t yet trust serious money towards Bitcoin. On the other side, what good is a worldwide currency that only holds $1b in value? In 2010 there were over 800 billion EUR bills and coins in circulation. Based on this PDF by the ECB I presume 2015 we will hit 1 trillion EURs in circulation. Based on the Statistical Data Warehouse of the ECB, 2010 saw roughly 4.5 trillion EURs in salaries. And Bitcoin is global, making 1 billion USD not enough value for global transactions, actually approaching 2 billion as we speak.

This will seriously be something to watch. Looking forward to your thoughts.

My Brain Hurts

Business, Managing Information and Finance, MBA Creativity, Innovation and Change, Software Development March 23, 2013 Leave a comment

Yep, it does and I thought I’d sum up a little bit how my day was. It all started slowly and gently with a sushi lunch meeting with Jörg vom Capnamic on wednesday. Then came a family thursday that was just wonderful. Next up, friday.

I started the day with Marc Kley from the Cologne University, responsible for “Transfer” … making real startups out of ideas in the university. He is also handling the HGNC and for today explained to me a little bit the structure of the university and the startup ecosystem there. This 9:30 to 10:00 and from then until 12:30 Marc had scheduled 30 minute talks with 5 Startups from the University. I will take a bit more time to possibly go deeper into them but my expectations were exceeded. I learned about the food industry and innovations in data tagging, got to know more about forestry and drones, helped further develop an interesting recruiting idea, discussed risk related graphdb topics and brainstormed the connection of ecommerce and local stores. Extreme fun and I am looking forward to the next one.

Then I ran and got to my next meeting where I learned more than I expected about the energie and smarthome market. I will need to go through my long notes to get that one down to paper. And with that discussion still eating away in my head, I ended up talking about innovation with somebody with lots of experience in that space.

I think I now need a weekend to really reorder my braincells. At the moment I have high hopes that next week will be a bit more focussed on order instead of more chaos. :)

Good Developers are like Milk Cows

Managing, Managing People, Software Development September 28, 2012 1 Comment

The idea came to me in bed, bare with me a second, it turns out it is a great analogy :)

First thing to know is that cows give milk best if they get new calves every year, and please let’s leave the judgemental part of whether that is good out here ;) But this already is fitting. The very good developers need a new baby, something fresh to work on every year at least. A new idea, a new part within a platform, a new challenge.

Then we have the weather, and it looks like cows are again similar. Most developers want to have a good working environment that has the right temperature. It’s really a general thing with people. We tend to not work well if the office is 30 degrees. The same thing is true for cows, who actually give milk best around 20 degrees.

There is a big report on cow behaviour and milk let-down, that provides further insights. As you see there, cows will not approach very bright light and need their own social space in view of the leader to be able to follow them. Cows can also adapt to new situations but you need to allow them to move at their own pace at first, trying to remove any fearful experiences along the way. If a cows position changes constantly, they cannot really adapt and will not give a lot of milk, like developers who become unproductive in a too fluctuating team. If cows are handled badly by a person, they tend to link that behaviour with the place it happened in… so they will be more productive in another company if they do not get along.

We all know the flow, the kind of hormon that you get when things are really working, when the right stimulus is applied, and again, for cows this is the hormon oxitocin that helps milk let-down. The important thing is that this stimulus can come from any sensory signal and to really move to good milk let-down you need to work on finding those stimuli in a cow and make it reproducible.  Important again is the absence of fear or pressure. This will not work.

Important to know is that bad influences that are stress inducing, will likely have an effect for weeks, and only after that time the cow will become relaxed again and be able to let the milk let-down flow freely.

Newcastle University then found out that if you want your cow to produce more milk, get to know her. Call her by name and build up a relationship. Make her understand that she is important for you.

There is further information for the handler right here. Important is to remove excessive noise and use positive interactions more frequently. Examine their routine habits and remove those that lead to fear and minimise negative or painful and unfamiliar milking procedures. Keep everything consistent and rather move them as a group than individually.

I hope you now all learned something about getting the best code out of the developers. Now go stroke your cows ;)

Update: I just remembered, here is a great post with a connection to the herding theme ;) Nerd Herding by Cal Evans.

The solutions for the plain text nut

Business, Software Development February 20, 2010 Leave a comment

I have a further evolution of my Rememberall. It’s really staying mostly the same but I have added three things to further allow me to work efficiently.

You have to remember that I am a text nut. I like stuff in plain text files. I like writing down stuff quickly and knowing its there somewhere without worrying where.

So one of those apps I added, via MacBreak Weekly or TWiT I think, is Notational Velocity. It’s a mouseless text entry system just made for quick text entry and retrieval. You have one search box, searching all your notes. Whenever you press enter a new note is created, when you press down you go into the list of notes. Simple as that. The fun extra thing is that you can tell Notational that it should store all texts in text files, which in my case get stored in a special directory that is synced to Dropbox. Oh the joy ;)

I have been working with notes like that for some time, but mostly in TextMate. The thing that is missing is easy access to the notes from the iPhone. Welcome Simplenote! It’s a website where you can write text files and see them and they have an iPhone app and an API. Hence, now my Notational Velocity Syncs with Simplenote on my iPhone, and thanks to the pro Account all text files are backuped and I got an email I can simply send stuff to and have it converted into a Simplenote. I can also get an RSS Feed from my Notes. Oh the joy! :)

So finally I have the solution I needed to have my written notes with me all the time.

The other one I just bought for the iPhone is Momento. It’s not perfect yet but it is going in the right directly. It is kind of a personal diary but the nice thing is that it can backup all your twitter items and flickr items and last.fm items. Now I am not using last.fm that much, but this really makes me wonder. I already suggested to the developer that they integrate more services and make me pay one by one. I would happily do that for Foursquare for example to add location to the diary. It might also solve my full backup bit.

Oh the joy! ;)

But I am repeating myself.

Running a Startup on Agile

Software Development, Web Development December 20, 2008 Leave a comment

I have this one sitting in my “To Blog” bookmarks list for ages now, so here it goes. It is actually inspired by a great post by Eric Ries entitled “A new version of the Joel Test“. The original Joel Test was written in 2000 and Eric tried to update it a little bit based on his experience in software development in agile teams. Same as him I start with Joel’s list.

  1. Do you use source control? Yes, essential and check.
  2. Can you make a build in one step? We have continuous integration, so check.
  3. Do you make daily builds? Well, building continuously would qualify I think. Ok, we could always do with more automated test but we are doing ok.
  4. Do you have a bug database? Sure, check.
  5. Do you fix bugs before writing code? There I am with Eric, yes we try to, but bug is not bug. There are some things we accept to fix later. But we do have an ASAP list that gets precendence over anything else.
  6. Do you have an up-to-date schedule? Here I again agree with Eric, damn I agree aa lot with him, but that’s the point. What we learned is that not the schedule is important, but keeping sprints short. As soon as a sprint goes over more than 2 weeks we have a problem of too big a backlog for the next one, too long testing, too much waiting, too hard to test features and the like. Our progress, which is what it is about, is better with shorter sprints, which take less planning and can actually be planned on the spot.
  7. Do you have a spec? Eric rephrases that into “does the team have a clear objective?” Yes, this is what is important. We try to have a 1-3 sentence goal for each sprint. Everything is aligned to that. There are then cross functional teams that build the spec. In the first meeting we create scribbles, get the features down, try to make the interactions clear, and go from there. This first meeting is very important though and we have failed in this before because you need the cross functional team there and you need to discuss things to the end and fight it out and the team needs to stay fixed afterwards. This is sometimes hard, but very important.
  8. Do programmers have quiet working conditions? It’s not one size fits all. Two of our devs moved out of each others office because one likes to hear to music and one likes it quiet. Some want company, some don’t. You need to enable that.
  9. Do you use the best tools money can buy? We try to and this should probably be taking up a bit more, but hey, we are a startup that watches the money.
  10. Do you have testers? Everybody writes tests first and then codes, as best possible. Yes, we have somebody responsible that makes sure everybody does that, but developer is developer. This is still to be decided in my mind. After a certain team size you probably need someone that takes care of the infrastructure, enabling automated testing by developers, and builds new test cases and handles the release process. But for small teams, it’s a team responsibility.
  11. Do new candidates write code during their interview? We didn’t do that yet, but more or less knew the people we hired, so it wasn’t so necessary. What we would be doing more in the future to give a new developer full responsibility for a new feature that is laid out so that it interacts with the entire platform. Then let everything be discussed in the weekly code review.
  12. Do you do hallway usability testing? Majorly lacking here, sorry. We are trying to keep iterations short but will probably have to do some learning in this field.

Next up are some of his suggestions. Yes, we do work in small batches and through daily scrums we know who is working on what and hence there are little conflicts at checking. He also talks about practicing the five Whys which I remember from the MBA. It’s a great idea. Why is it a great idea? Because it allows you to think up till the root cause? Why does that help? Because you don’t fix something that does not need fixing but what really went wrong. Why? Because after the first idea you ask why again and go on from there… get the point? 5 Whys. It’s a great system and oh so simple.
He then goes on to talk about the difference between defects and polish. This is very important to understand. We build a feature, often taking the easy way for the interface (after we learned building it complicated first is nuts ;) ) and how it works but making sure there  are no bugs, that it works, and does so reliably. From there we can build polish if need be. This is a subtle difference, but an important one.
His last point is probably the most important one: Does everyone (he names programmers but that’s not enough) understand how what they are doing relates to the company strategy, well being, vision, day to day business? This is where the cross functional teams help. It helps programmers understand what people do. A good developer will go nuts finding out that somebody sits there doing something in the interface for 2 hours every day when the dev can whip up something simple and get that down to 5 minutes. But you need to have communication.
That is actually one thing that I would like to add. The most important thing, and the reason for being of Agile, is that you have communication. The entire point of now doing waterfall development is that you know that the biggest problem in software development is that people speak different languages. Every party will need to try to work out what the other party really means. That is hard, and painful sometimes but only understanding will lead to good code.

Web Application Security by Mario Heiderich

Software Development December 12, 2008 Leave a comment

The book is in german and called “Sichere Webanwendungen” and Mario is not the only author, but having been one of the key people at Ormigo, I thought I’d mention that a book he co-wrote is out. Other authors include fukami, Christian Matthies and Johannes Dahse.
And if somebody knows what web site security is about, then Mario is the man. So much so that he can get on your nerves some times and I say that as the higest form of flattery ;) . On a side note, he developed PHPIDS at Ormigo.

Structuring your Development Environment

Business, Software Development April 30, 2008 1 Comment

As Ibo just posted about Sevenload’s Secret Garden strategy, I thought I’d wage in with my own thoughts on structuring your development environment. We see ourselves as a technology company at Ormigo, mainly because we do not believe the local market problem, getting it online, will be solved with a sales force.
Ibo’s article is in german so I will try to translate a few of his views and comment and elaborate. He is only giving a few insights, but they are relevant none the less. The basic idea is to build an environment that helps to build great products.
What Ibo has developed, with Tom and Axel, is to put the developers in a “hermetically sealed” environment, meaning they are behind closed doors. The general idea is good in that you need to get into a flow and disrupting developers in their work is bad. Fully closing the door and letting nobody in is an interesting concept and I am looking forward to hearing more of how it works. From my personal experience I would argue that you then need core teams and an operations team and that operations team needs to be in another room, because there are operating things that need to be discussed shortly.
The other big problem with this closed door is that you loose communication, and the most important thing in software development is communication. That is the entire idea behind scrum, which he hints on later. Of course the communication needs to be structured, but based on his idea, there would be no problem having teams dispersed over different countries, especially because he says that most communication goes over an internal IM client.
He does say that developers need the right gear and among others two monitors. We have been doing that from the start and it is proving very valuable, but it is not limited to developers. Especially if you say that developers need a laptop, buying a second 20+” monitor is needed and the price point is not so much different from a desktop system in many cases. One thing I like is his idea of having large flatscreens on the wall that give the status of the servers and features in development or just launched.
There are no walls between people in the same group, which I agree too, but only glass walls between different teams within development. We actually have smaller rooms here, with 2-3 people in development in one room because some people need to close the door from time to time. That is really his secret garden idea but tailored to the developers that want it like that and those that don’t.
His basic ideas of a secret garden actually fit to scrum again and also are often common sense, like not fighting but discussing. But that is a culture thing and the culture at Ormigo can sometimes seem rough. This is an extension of having people with experience and clear views in the company though, and we can all disagree vehemently, discuss things and then come to the conclusion for a plan to follow, because each view has been heard and we can then agree to disagree but agree on a plan. That is very important, and needs a good managed of a meeting culture, which is independent of the secret garden system though in my mind.
He also says that they have only structured discussion among small teams, also with different departments, which is fully reasonable. It fits with our meeting system for bi-weekly deploys. In the middle of the current sprint we have a short meeting with everybody for an update of the current sprint and discussing the next sprints high level goals. There we also discuss who is responsible, which will be one person from bizdev and one developer as a minimum. That allows for rotating responsibilities through the entire team. This small team then makes sure to get a better idea about what the next sprint will be about showing that in a short meeting over lunch at the end of the week. Next monday we normally deploy our current sprint, and then go down into tasks for the following sprint, splitting up different tasks for different people in kind of sub-responsibilities. Then the system starts over. So yes, you need small meetings, clear responsibilities, but you need very semipermeable walls between each department in the company, while being clear that you don’t just walk up to somebody and ask a short question (which is hard sometimes).
Congratulations for using JIRA as a task management system, even though I am not sure if it does not create too much task management overhead. Doing development for corporations that might be needed though. We are using Trac internally and are feeling very happy with it because it allows us to easily handle small sprints and mix around tasks. Yes, there are no task dependencies in the system and no required process flow, but that is not needed with the right structure behind it and small sprints. These interdependencies are only needed if you do a 3 month sprint for example, where you start to need a real project management. Interdependencies are for us between sprints on a higher level.
He also says that often you loose yourself in technical details, which is something I can only agree with. This is why the development team needs to know the business side and the numbers and the real goals. Goals are not “build feature x” but “get more SEM traffic” or “allow more ratings” which can be measured afterwards. The technical detail bit is actually what makes the difference between a great developer and a good one. A great developer will know what is needed and what is overkill. You should not die in beauty. But there again the bi-weekly deploy system works very well in that it requires you to focus.
Looking forward to hearing more from Ibo about their structure and how it is working out. Scrum is great but real Scrum is REALLY hard.

Second Life User Numbers

Life in General, Software Development, Web 2.0 December 29, 2006 Leave a comment

This was already a small controversy at Le Web 3, though many might have overheard the question posed the the guy from Linden Labs on stage. The thing is that Second Life is saying they have 2 million users and it seems more likely that they have something like 10-20.000. Clay Shirky did a very insightful post on this called A story too good to check. Really worth a read for all those claiming that Second Life will change the world. I still think there is a possibility that this will be amazingly huge, but it will likely take years. I actually had an idea several years ago with friends of starting an online world for educating kids, which I still think is a great idea. I mean allowing kids to learn in an evolving online world (“This is a cow, it makes muhhhh and eats …”), in a secure environment, adapting to their abilities, would be wonderful. I am not sure yet that things like SL are really what some call Web 3.0, believing more in automated agents as the next big trend, but we will see how this game plays out in the next few years.

Nine things developers want more than money

Software Development, Web Development November 5, 2006 Comments: 4

Very good post over at Software by Rob. It’s about the important things that developers need to work happily at your company.

He places everything in two parts. Hygiene and Motivation. This is actually very similar to Maslow’s hierarchy of needs something that is always again turning out to be true. Maslow put motivation into a hierarchy.

  • Physical Needs: working conditions, wage, housing, catering,…
  • Safety: health insurance, pension provision, safety, security in job
  • Social: sports, clubs, parties, outings, open communications, …
  • Esteem: Regular positive feedback, prestigious job titles, promotions
  • Self-actualisation: challenging, encouraging, can structure own work

The idea is that you need the first parts like with a pyramid. If the base is not there, it is futile to add the others. In bad working conditions, no amount of challenge will lead to motivation.
The same thing is true for hygiene. You need it to start with. Or at least a good amount of it. Maslow is actually a bit clearer that you need the base as a must have.
So let’s put this more into perspective for developers.

1. Being Set Up to Succeed
The idea is that you really want to build something, something that doesn’t put unnecessary road blocks in your way, that is maintainable. It needs to be a quality product. It’s craftsmanship. You don’t tell a craftsman to build a crappy table. I am happy to be able to put a check here.

2. Having Excellent Management
You need to take bullets for your team, no micro-managing, give them free the freedom to think themselves. This is really too early to tell. This really takes time to build up. The verdict is still out.
3. Learning New Things
It seems that if your job gets more variety, and you get to acquire new skills, you will forgo a 20% raise. A really good developer needs to learn. Of course they have to want to, which is kind of a circle. Good developers do. This is a kind of test. I am making damn sure they have the option.

4. Exercising Creativity and Solving the Right Kind of Problems
I think I have to try one suggestion he has: drop a Sudoku in the middle of the developers to see them attack it. Might be a good trick when hiring somebody new. :) I agree that developers love challenge in general, so a big job is to make sure that the problem at hand is a difficult one. And remember, easy problems can be difficult if put in the right light and made into a challenge.

5. Having a Voice
When a developer speaks, somebody has to listen. Simple. That’s actually true for all people I’d say.

6. Being Recognized for Hard Work
Peer pressure. Something Google uses as a management style. Hard to make right and not backfire.

7. Building Something that Matters
Building something that somehow has more reason than making money. I think we score big there at Ormigo, because we give local merchants an option to compete in the global advertising market.

8. Building Software without an Act of Congress
Let them build it. Don’t talk about building it, but build it.

9. Having Few Legacy Constraints
This is really a cry for refactoring and putting that into your development model, making time for it. The thing is that you don’t want anything in your app to hold you back. But as you are learning along the way, the stuff holding you back will appear again and again.

I actually have to say that we are doing pretty well at Ormigo. A lot of this can be read out of simple management practices from an MBA if you look at it from the right angle.

The Google Management Style

Moblog, Software Development October 6, 2006 1 Comment

I recently found two interesting articles relating to Google’s management style. It starts with Steve Yegge talking about Good Agile, Bad Agile. Working along the agile development approach with some changes, this obviously interested me. In a sense he is right. On it’s own, without adaptation, without thinking, it is another fad that consultants will exploit. It is also true to many other things I have learnt about people management, so the general ideas underpinning agile software development are right.

After having worked at Google for some time he thinks he has understood the development process and I will take his word for it as the insights he give ring true.

They are not really using managers as such but mostly tech leads as they code themselves. In the end, I believe developers choose their tech leads themselves as different people have different skills and the “lead” part should be taken up by those with the most developed necessary skills of the moment. Management’s task is to facilitate that and get out of the way.

Another point is that you as a developer can switch projects and teams at any time. This of course requires a big company, as you need some amount of projects, and you need some system to make sure every project is filled. But more to that later. That you can spend 20% of your time on other projects is known and a good idea if you have the right people that will work on related projects any way as that inspires them.

They also have very few meetings, which again comes with clearly defined projects. “Make the search results appear faster” doesn’t require a lot of meetings other than with your collegues over a brainstorm.
The interesting thing is that there are no Gantt charts of date-task-owner spreadsheets. Nothing resembling project management as such. We are moving a similar way though. The thing is a Gantt chart doesn’t make you faster. Identification with the vision does.

You also don’t work insane hours (“unless you want to” with the “want to” being pushed a bit ;) ) which again relates well to Joel’s point that 8 hours of creative work are all you get out of people. With 12 hours they are bound to do other stuff and you start getting higher turnover. If you do it all the time.

One important part that I didn’t know up till now is that a large part of Google relies on incentives. Your reward is in relation to how important management sees a project. The incentives are financial and in other forms. The “other” part comes from Google’s peer review culture, which I posted about recently. If you have good people and a peer review system, with financial rewards tied to peer reviews to a large extent, then the review of those peers, people you respect because you know they are good, will have a large incentive component. Check this:

“I might have been mistaken, actually. Having your name and picture up on that big screen at End of Quarter may not be the biggest incentive. The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude. You can’t help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.”

All this does though is to get people to work on the right projects. The best explanation is his first sentence on this:
“At Google, projects launch because it’s the least-energy state for the system.”

Ok, there are project managers, and product managers and all that. But they really only nudge. Teams sit together, lots of meeting rooms are there. Meetings happen in the middle of the day, and people come in early or late to keep the rest of the day to working.

But again the small pionts matter. Google takes “things like unit testing, design documents and code reviews more seriously than any other company”. That results in them having one code base, and switching teams and sharing code becomes easy.

The other thing is that Google is not date driven. Their drive is their desire to build something. Google wants things done as fast as possible. You need to create that urge.

Something I agree with is that index cards are not the optimal solution. We are actually using FogBugz here and it provides us with a good work cue, per project, per release. If you add time estimates it gets even more powerful but they tend to be a pain in a smaller organization. Don’t mistake this for trying to control people. It is just to have an idea of how much work is in front of you.

I also agree with him in that you can’t do too many sprints or too short sprints. You still need a bit of freedom. We are currently using two week sprints, but something have a break of a week in between or just cleaning sprints. What the sprints do help with is having a bit more structure above and beyond projects. Of course you can work on the next sprint tasks if you want, but everybody knows that there is a clear goal with the current sprint and that goal is something we all want to reach because we know why it is there. The date at the end is just to give us a clearer goal.

Then there is the part I fully agree with. You can do things, that are not really part of the sprint, but that will improve your productivity immensely in the remaining ones. I could make a sprint saying that this one does not have unit tests in it, or that the idea to move our javascript interaction to it’s own framework will cost us time … but that is short sighted, and this short bit might be super short.

Then Greg Linden talks a bit about all this incentive stuff. Gives it just this other bit of certainty.

Follow

Get every new post delivered to your Inbox.

Join 1,881 other followers

%d bloggers like this: