Category Archives: Software development
Customers who are unable to explain what they really need, marketing guys that make up their own stories, and project owners that won’t take the time to give you feedback during the project. A recipe for disaster.
I’ve recently discovered Prezi, an online and fun alternative to powerpoint. So I decided to make a little prezi-based blog post to test it out. Enjoy!
A late project? Well, it has been known to happen. According to my wife (who has got a far better memory than me), almost all my projects are late.
I attempt to explain that they are not really late, someone has just decided to add more features. Or we all decided to postpone the release, to make sure the delivery had the required quality. Then she goes “But the project was supposed to be done last tuesday, right?” and I’m like “Yes, but..” and she cuts me off “So that makes it late.”
A popular term is “definition of done“. Maybe we should also discuss another: “Definition of late”. The definition of done may be challenging to define, and across an organization it’s very likely to mean different things to different people. One would think that definition of late should be easier to define.
“The project should be done by November 1st. If it isn’t, then it’s late!” Right. But wait. Done? If the project isn’t done until September 1st it’s late. Suddenly avoiding being late relies on something being done – and we just agreed that “done” is a tricky topic. Or is it?
When we postpone the release to production in order to do some additional QA, we’re not really late right? We’re done with the project, we just haven’t released it yet. That must be okay? Or does the lack of quality mean that we tried to deliver too much in too little time?
And if the project owner asks you to add more features, surely that’s no problem. He is the boss, after all. I suggest you explain to him that it will postpone the delivery of all the value created so far. A better solution would be to deliver what we agreed, so that the project outcome will benefit the customer as soon as possible. Then we can add more stuff in the next round.
So, back to being done and late. You see, the thing is that the customer rarely considers a project as done before he can create value from the result. So if your customer can’t create the expected value from whatever he ordered from you, then you are not done.
And if the customer can’t create the aforementioned value by the agreed delivery date, then my friend..
You are late.
As I’ve mentioned before, accurate estimates are hard. To make matters even worse, you will never become an expert at it.
It’s just not possible. If you practice enough, you may become an expert at playing chess or tennis. Why? They are both activities with predictable rules and clear consequences to any action. The concept isn’t difficult to grasp, in order to master it you just need to practice (a lot).
The saying goes that no chess game is ever the same, but an expert chess player will still have an intuitive feel for the game. Looking at a chess board in the middle of a game, she can immediately tell you the preferred moves and the likely outcome of the game.
Estimating complex projects is another story. You probably have to deal with unknown uknowns. There are the stuff you know, and the stuff that you know that you don’t know. But what usually kick you in the groin, are all the things that you don’t know that you don’t know. Any number of things may happen during the project that will dramatically affect the outcome.
To make matters worse, our brain has a nasty habit of completely ignoring unknown information. In the context of estimating, that means unless you know absolutely everything about the task at hand, you will underestimate the work required. You have to force yourself to consider the known unknowns, and include them in your estimate.
Your brain also loves replacing a hard question with a simpler one. And most of the time, you won’t notice. “Will it be a good investment to buy this house?” is a complicated question, that most people readily replace with “Do I like this house?”. Much easier.
The same thing happens when someone asks you to estimate a complex system based on some simple drawings of the user interface. Your brain goes into lazy mode, and attempts to replace the difficult question “How long would it take to design, build and test all the logic behind that system while working in a team of several people?” with the much simpler “How long would it take me to build a system that looks like that?”
And the answer to that question, as we all know, results in a useless estimate.
The third problem is that we are all too confident in our own abilities, and in hindsight we are usually convinced that we had a hunch or gut feeling about the true outcome of the project. So whenever a project goes over budget, we usually “knew” deep inside. We just need to follow our gut the next time! And whenever a project is actually on time, we have probably added features until we spent the available time. And whenever a project is delivered before the deadline…just kidding, that never happens.
So the next time you are asked to estimate something: Pay attention to your gut feeling, that is your experience talking. But force your brain to keep working. Consider what you don’t know, and be honest with yourself and everyone else about the fact that your estimate will never be 100% accurate. The larger the project, the more uncertain your estimate will be.
If you want to know more about how your brain works in relation to decision making and predicting the future, I strongly recommend “Thinking, Fast and Slow” by Daniel Kahneman.
I’m pretty sure that if a developer built a house, it wouldn’t have any corners. Their first instinct at the sight of an obstacle would be to get rid of them. Corners you say? Who needs them! And then they’ll all start chanting: Cut a corner, cut a corner!
At Revio, we challenge the developers to deliver estimates that they believe in. We tell them not to consider the expectations of management or customers. Consider the task at hand, and attempt to figure out how long it will take to get it done, and done right.
As discussed in an earlier post, accurate estimates are hard. That means even though we estimate with the best intentions, we might still end up hard pressed for time. And even in the flowery, sunny world of our little company, we occasionally misunderstand the customer. So there we are, with maybe 3 developers in the team, ten days until deadline, and 500 hours of work yet to be done.
Fig. to take shortcuts; to save money or effort by finding cheaper or easier ways to do something.
To do something in the easiest, quickest, or cheapest way, often harming the quality of your work.
In a situation like this, the vision of an unexperienced developer often narrows down to the very next line of code as he mentally calculates how to shortcut his way out of his misery. Must. Code. Faster.
Let me share with you what I as a manager would want the developers to do in this situation:
- Give me a calculator, help me type in 3 developers times 8 hours times 10 days equals 240 hours. Explain that we have 500 hours yet to be done. Then ask me patiently what I would like to do with the 260 hours worth of work that we do not have the capacity to complete.
- Tell me to read “The mythical man month” if I suggest to add another 3 developers to solve the crisis.
- Ask me wether moving the deadline is a viable option (More often than not, it actually is).
- Work together with me in order to figure what features can be moved to a later phase, while still delivering as much value as possible in the current phase.
- NEVER EVER cut on code quality (architecture, coding practices, coding conventions).
- NEVER EVER cut on quality assurance and testing.
If you discover mid-project that you have more work than you have hours available, you will not get everything done in time. Period. Going into a team-wide panic and start building up technical debt like crazy won’t really help. In the long run, it’ll just make things worse.
Often, quick and dirty actually takes even longer. This is especially true if you have poor specifications and need to do a lot of re-work. When you tell me “yes we can” when actually we don’t, that’s bad for both of us.
So in conclusion: The next time you’re stuck in a doomed project, make sure you stay realistic and maintain your own integrity. Your manager may ask you to get 20 days worth of development done in 10 days, but it’s up to you to accept it.
The guys in the agile community have been writing, talking and moaning about estimates for ages. “Accurate estimates are impossible! What’s the point? Let’s stop estimating, it’s just guessing anyway!“
Let me try to explain.
We all agree that we’re basically guessing, right? That may be the case, but if you live in the real world, you actually sell stuff for a living. In order to sell stuff, you need to have customers. And what’s the problem with customers? They usually demand to know what something costs before it’s produced. Go figure. Anyway, that means we need to estimate wether we like it or not.
A rough estimate from a developer or architect is usually the basis for a fixed price offer. If the estimate is good, you’ll make money. Sometimes it’s not, and then you’re up shit creek. If bad luck and an inexperienced developer team up, rough estimates can be several hundred percent off the mark. So why do we keep working like this?
The big problem with this transaction is trust. The customer rarely trust the software company enough to pay for a project by the hour. The history books are full of dishonest companies who have destroyed the trust in the IT industry. Now we all have to work hard in order to regain that trust. You need to convince each and every customer that you actually want to add value to their business by creating great software. That’s what we’re all about. Right?
If you gain enough trust within your market, I strongly suggest that you attempt to operate with budget limits instead of a fixed price. Agree on a minimum scope, and explain to the customer that you will do your best to include as much functionality as possible within the budget you have agreed upon. This way you reduce the risk on your end, and the customer doesn’t have to pay for the built-in risk premium of a fixed price. A better deal for everyone.
Great stuff, happy campers all around! Now we can stop estimating and focus on real work.. But wait a minute. How can you (or the customer) know wether the project will be worthwhile? How do you establish a reasonable budget? When presented with the required time to market, how can you tell if you will be able to deliver on time? You guessed it, by estimating. Seems like there’s no way to win this game.
To make matters worse, the game changes as you go along. As your company grows, your development process will change. You add quality assurance, you add a project manager. Your team grows, and suddenly lots of time is spent talking about how to do stuff instead of actually doing it. Challenging SLAs means more time spent on release management and server maintenance. The environment surrounding your team changes all the time, and the correct answer to “how long will it take to..” changes with it.
At the end of the day, an estimate can never be more than an educated guess. But fear not, all is not lost: If you manage to build a team with focus on quality, keep the turnover low and maintain a stable, honest environment with room for making mistakes – you might just end up with a bunch of guys that are amazingly good at guessing.
I’ve been surfing the web since it arrived in the 90s. So why do I still click several times on the mouse when a page fails to load within a few seconds? I know very well that with each click I’m sending another request to the web server. I’m basically stabbing it to death with my mouse.
So why? Because I’m freakin’ frustrated, that’s why. I grew up with MTV, if nothing happens within 3 seconds I get so bored I throw a fit or fall asleep. The average user sense a delay if it takes more than one second for something to happen after they click their beloved mouse.
So what does that mean in my world? It means that when developing a new web based service, focus on speed is vital. I don’t care how many great features you cram into the product, If it doesn’t look good and load fast you’ve still got a problem. Below are some basic guidelines when developing your new website.
- Surfing your service (loading the login page, logging in and clicking on the available menu items) should on average take less than one second per click, and never more than two seconds.
- Any action that takes more than three seconds on average need some kind of visual notification. Put in a a load bar or a blinking “Please wait” to make sure the user doesn’t forget that he actually did click when he wakes up again.
- Nothing (including reports) should take more than 10 seconds to load. Ever. That’s an eternity. Most people on Facebook was born less than ten seconds ago. If your report takes more than ten seconds, pre-fetch it and store it in cache or on disk. Or you can send it to the user async via email, so that you can respond to the user immediately with “Your report will be delivered to your email shortly”.
But what about the internet itself, you ask. My server is super fast, but my site still loads slow for some customers! A study showed that on average it takes 6 seconds for a page to fully load. Only 0.6 of that time was server processing. 1.4 seconds was the actual network traffic, and 4 seconds was processing on the client computer.
So your code should be lean, just as your development process. Hopefully your service is about improving a process that creates value for your customer. That means the faster your service is, the more value (and less frustrated) your customer will get.
So the next time your customer or product manager asks for an animated duck in the background of the new administration interface, make sure he knows that it will slow down the load time of each page with several seconds. When you ask “Does the duck add value?” and your product manager says “Yes”, you can kick him in the knee and tell it’s from me.