Sunday, October 23, 2011
Puzzling Hiring Problems
Developer Categories
So, you can't find a decent software developer to join your team? It should not be a surprise. Good developers are rare birds; very intelligent, introverts, detail minded, problem solvers, independent. I don't want to put people in a slot, but this is how developers often are. There just aren't that many sufficiently "brain damaged" people around who like to torture themselves with menial and time consuming problems that take deep concentration. You know, the kind of book worm stuff that people hate when they go to school etc.
You often see a a category of applicants who claim to know programming, but they don't. They usually fail even rudimentary tests that you put in front of them. They are just fishing around, thinking that they can just grab a job and do a bit of good ole hacking on the side. These people don't really want to be software developers on the long run, even for the money. This group of people are a waste of time for anyone who wants to hire a software developer. They won't get much done, and what they get done, sucks.
We have software developers who tend to be careerists. They go to work and write software to get a pay check. They might be introverts and have some of the characteristics of good software developers, but they are only marginally committed. Nothing bad there. Most people you hire are probably like this. They get things done, but it's just not going to be anything more than average. They also mostly expect the work to be handed to them with full requirements and instructions what to develop.
And then there is the group, who is above the average. They care what they do, and they want to write software. They want to learn and they are motivated. These people are good hires, because they also get things done, and over time, they can do things that careerists just won't ever do.
The problem with the last group is that the ones that really have honed their skills are just not out in the open for the grabs, unless you are lucky. You simply rarely see them.
Engineer vs. Designer
Perhaps you have then hired someone suitable enough. They might be talented, and eager to do the job. They produce results and get things done, at times. But something just does not really jive. This seems to be true too; some developers enjoy the theoretical aspects of the profession, and some just like to slap things together quickly.
Either extreme does not work well. You don't want the architecture astronauts, or the cut and paste hackers, but you do want something in the middle range. This is because theory matters when it is put to good practical use.
You sometimes see people get stuck designing all kinds of lofty ideas that are not really relevant to the problem anymore from the practical perspective. It can be fun to think about, but it's a disaster waiting to happen in real life. It can take different forms; mindless use of tools that do not solve the practical and real problem (because in theory it could work), stuffing layers to software that only add to complexity (because it's what the best practices are). This is the designer trap that people sometimes get into.
Opposite can happen. Software is getting done fast, and quickly, but it is all in the name of getting it out the door in what ever way. It's bad software, hacky, copy pasted, sloppy, not well thought out, without any decent structure. Sure, it can work but only in small scale. Bigger software, critical software, and long term maintenance of software are those key areas where this kind of "getting it done" approach will create a disaster. It's perhaps what happens more often than over-architecting because things are being done and there is the feel of great progress. Managers especially love these kinds of people who turn around on a dime and "get things done".
To a significant degree these two kinds problems emerge from lack of experience. People are just good enough to produce results but the wisdom, intuition or true skill is not there to reign in the bad behaviors. Experienced people are simply far more balanced and know how to manage the outcomes.
Introverts and Extroverts
Some people are more social than others. Some people are more detail oriented than others. Some can solve problems better than others, and different kinds of problems. Some people are glib, some are not. What do you really want to emphasize in a developer?
There is the argument that now that we are doing all this Agile stuff that developers need to be really social and engaging, eagerly embracing the business, while at the same time you want them to produce brilliant, well thought out software that comes out like clock work, and never misses a deadline. Well, easier said than done.
I mentioned that most good software developers are really introverts. It's still true, in my opinion. It does not mean they are not social enough, but they are not the ones with the gift of the gab and "social engineers". They mostly focus on solving "non-people" problems that are eternally boring to the vast majority of people. These people stay focused on the technical aspects of getting things done, formulating complex things and making it real in terms of good software. It requires lots of concentration, free from unnecessary interruptions.This regardless of all the buzz about agile pairing etc. I don't think it always works; have never seen it work for real, in fact.
I think you want some kind of mix here as well, slanted towards the introvert types. If you want a good reliable software developer, you need that quieter type who gets things done with good workable design skills, who can still interact successfully with business and product owners when required. The onus for successful interaction is often put on the developer, but I think this is wrong - why not require equal attention and skills from business/product people when interacting with developers, to be able to understand enough what the developer is saying. IT functions are now so central to businesses that having business people who do not understand their IT operations is really a bad thing.
There are places for extroverts as well, in the agile realm of things. A good Scrum Master is often someone who's an extrovert, but they necessarily do not or should not lead software development from the trenches. Their focus tends to drift away from what is required to produce good software in practical terms. These kinds of people tend to jump around from one thing to another, relishing the opportunities to get things done quickly and moving on. Software development might interest them, but not in the sense that is required to become good at it.
The bottom line - don't expect developers to be socially gifted, while at the same time being great at building good software. It just does not work that way. We do not elect, nor often see politicians who are introverts, so why put unrealistic expectations on software developers? Brain, and the way it works matters when it comes to different kinds of jobs.
Sunday, October 2, 2011
The Estimation Game
Recently, there has been various articles and blog posts about project or work estimation and whether it is worth doing.
What are the reasons for doing estimation?
This sounds simple enough but it really depends. The problem really comes in with the size of the work.
Bigger projects have so much variability and unknowns that even the best attempts to estimate work up front will likely fail. It is hard to know what in fact will happen and the outcomes depend on the flexibility of the overall plan and the attitude of the team and the stake holders. The real problem here is that estimates become an unchangeable plan, and then they also become time commitments. When you fix these two things you have nowhere to go when surprises occur and new work is invariably discovered. On the other hand, if you are flexible, large swaths of the project plan might change on the way and budgets and time lines might actually have less relevance in the overall process. Also, the human component is so dominant in long running projects that it is very hard to guess what the output of the team is, especially if the team keeps changing along the way.
Smaller and often unrelated work items can be estimated quite easily and there are far fewer surprises. However, this kind of workflow often has so much flexibility that the work plans keep changing from week to week. Many of the items that are estimated will never be worked on and new items are inserted to the work flow. It might be that there is a lot of churn and time spent on estimates but at the same time it is quite well known how soon work is completed when it is started anyway. If you put a work item on top of the priority queue you can expect it to be done within the iteration, as will many other items reasonably close to the top of the list. Further down in the list the item is, less you really care about it, and the stake holders might never really care about it at all after couple of iterations.
So, where is the value? I think the only real value is the ability use living estimates as a decision making tool.
In the long running projects, you only care what the estimate is NOW. It could be different from what it was a month ago, and it will be different in a month from now. You will gain experience what the team can do over time. That will give projections for cost and completion times. With good enough management of priorities and the value of the feature set it is possible to approach something attainable. Also, there must be openness to react and change the plan. Staffing changes will provide additional challenges but on the long run it is possible to gauge how the project is doing over how the team is doing in the project.
There might not be so much value at all doing estimates for variable short term work where experience will quickly tell what the 'event horizon' is because you only really care about the immediate results anyway.
This is still somewhat simplistic analysis because it does not fully appricient the complexities of understanding work, producing right results, dealing with feedback and inspection. Building the right thing is still the most important goal and measuring that is very esoteric and based on things that are hard to measure. Many teams can call things done and can appear to make progress but what exactly are they producing and how? Sometimes you see those high profile failures that leaves you puzzled - obviously it was considered done, and all the rest, but it just did not work. Obviously the estimates were wrong, even when budget goals or time lines were met.
What are the reasons for doing estimation?
- Know the size of work.
- Know the cost of work.
- Know the staffing.
- Know when you are done.
- Known requirements/features.
- Changing/unclear/missing Requirements.
- Knowledge of the Domain.
- Skill of staff.
- Changing Staff.
- Feedback/communication.
This sounds simple enough but it really depends. The problem really comes in with the size of the work.
Bigger projects have so much variability and unknowns that even the best attempts to estimate work up front will likely fail. It is hard to know what in fact will happen and the outcomes depend on the flexibility of the overall plan and the attitude of the team and the stake holders. The real problem here is that estimates become an unchangeable plan, and then they also become time commitments. When you fix these two things you have nowhere to go when surprises occur and new work is invariably discovered. On the other hand, if you are flexible, large swaths of the project plan might change on the way and budgets and time lines might actually have less relevance in the overall process. Also, the human component is so dominant in long running projects that it is very hard to guess what the output of the team is, especially if the team keeps changing along the way.
Smaller and often unrelated work items can be estimated quite easily and there are far fewer surprises. However, this kind of workflow often has so much flexibility that the work plans keep changing from week to week. Many of the items that are estimated will never be worked on and new items are inserted to the work flow. It might be that there is a lot of churn and time spent on estimates but at the same time it is quite well known how soon work is completed when it is started anyway. If you put a work item on top of the priority queue you can expect it to be done within the iteration, as will many other items reasonably close to the top of the list. Further down in the list the item is, less you really care about it, and the stake holders might never really care about it at all after couple of iterations.
So, where is the value? I think the only real value is the ability use living estimates as a decision making tool.
In the long running projects, you only care what the estimate is NOW. It could be different from what it was a month ago, and it will be different in a month from now. You will gain experience what the team can do over time. That will give projections for cost and completion times. With good enough management of priorities and the value of the feature set it is possible to approach something attainable. Also, there must be openness to react and change the plan. Staffing changes will provide additional challenges but on the long run it is possible to gauge how the project is doing over how the team is doing in the project.
There might not be so much value at all doing estimates for variable short term work where experience will quickly tell what the 'event horizon' is because you only really care about the immediate results anyway.
This is still somewhat simplistic analysis because it does not fully appricient the complexities of understanding work, producing right results, dealing with feedback and inspection. Building the right thing is still the most important goal and measuring that is very esoteric and based on things that are hard to measure. Many teams can call things done and can appear to make progress but what exactly are they producing and how? Sometimes you see those high profile failures that leaves you puzzled - obviously it was considered done, and all the rest, but it just did not work. Obviously the estimates were wrong, even when budget goals or time lines were met.
Thursday, September 1, 2011
What is Product Design?
As a programmer, how do you answer that question? What is Product Design? Not oddly enough, people have a wide variety of opinions what really is product design. Ask a product manager and they think they are designing, ask UI designers and they think they are designing, ask a programmer and you get the same answer.
I came across these two posts about the topic:
I came across these two posts about the topic:
One is asserting that web designers that draw pretty pictures are really not doing the full round trip in web design. The other, which is a response, argues that programmers who do not do CSS and graphical design are not designing the whole thing either.
Both would be right, but the argument is just pointing to a dysfunction in typical design roles. There are so many aspects to design that people can't often do them all. However, if you are looking for some kind of ultimate solution, you want a virtuoso who can do it all. At the same time, it is probably not too much to ask that people actually cross different disciplines. Often, that is better than mastery of programming alone, for example.
It is fine if a web designer draws images. It's a bit like making a rough sketch before the actual work starts, just get some idea about the web site. However, I would argue that there is still a big gap between that and actual design that is sufficient. Mastery of HTML and CSS should be required from web designers. And more than that, a real understanding of functionality and usability. This is the kind of middle ground that is very important but it is left in the no mans land, and that's a big gap in deed.
Programmers should know about HTML and CSS. Programmers can be a great asset in organizing and helping design here. Programmers are usually very particular about the aesthetics of organization, rules, practices. Programmers should know about usability, and how software translates to user experience. This is not important only because it makes user's life easier but it also affects how software is designed, and therefore it makes programmer's life easier.
There is a nice symbiotic relationship that can be created here where web designers, functional designers, and programmers can cross disciplines and interact in a positive way. It is easier said than done, of course. I have long argued that web designers should be integrated to the programming teams as full fledged members. In agile terminology, it is all matter of definition of "done". How can you really separate web design from programming, when all of that is in the cross roads that makes software great, or not?
Monday, July 4, 2011
Agile Golden Hammer
Now that the Agile movement is well past the early adoption phase, in mainstream, people have started to complain that Agile does not work and the research seems to show that Agile adoption often fails on many facets. While it is true that Agile is not always the solution, it is also a fact that people do not GET Agile.
Just get some basics right. It is not rocket science.
Just get some basics right. It is not rocket science.
- Agile practices work when we are in creative work environments, often requiring individual skill , knowledge and creativity. There are no repeatable and simple steps to complete work.
- Create space and autonomy for people who are doing this demanding creative work. This kind of work requires a lot of concentration, and time. Avoid interruptions.
- Focus on learning. What ever makes learning faster, getting feedback faster, getting to the next level faster - do it. Usually this means small increments of work, learning from it, improving, and doing it again. Experiment, get to the solution, and then do it right. Hack when you start, but finish solid.
- Get the teams right. Cross functional does not mean a group of developers. It means designers, testers, developers, business people, sales, all in one package, in one unit. If you can't get most (if not all) of your work done from end to end with the people in your team, you are limiting yourself. Not always possible, but strive for it.
What not to do:
- Start with Scrum, and do Scrum one year after. Scrum is a starting point, not what you should end up with. Dogma kills.
- Expect Scrum etc. to solve your problems. People solve problems, people improve. Scrum remains the same, no matter how hard you try . If Scrum does not seem to work - don't use it. Instead, find what does work.
- Expect people to just jump in and get it. Sorry, I don't believe this is even possible, unless you are in a very coherent and cocooned environment with like-minded people. Most people don't care about Agile, Scrum or any gold plated buzz word. Just go and do something - don't try to sell Agile.
Friday, September 24, 2010
Thoughts on Message Queues and HTTP
I have been facing this dilemma for a couple of years where I find a need for asynchronous loosely coupled communication.
Naturally, I would turn to use message queuing as a solution. What I found was that while most queue products claim to be very performant having a high throughput, none of the ones I have tried managed to deliver on reliability consistently. These products are great if you only need a best-effort, non-guaranteed, asynchronous communication channel. But sadly, when the reliability requirement is added (that is durable queues and topics) the complexity of the solutions becomes a problem. Not only that, but there are often other limitations that come into play - like performance problems even for low throughput requirements in the low hundreds of messages per second.
If you look at my requirement list, it is doable with message queues - absolutely. The problem is that it is very hard to do well the way message queues do it. The root of the problem is that durable subscriptions are tracked within the server. When the message delivery is tracked at the server things suddenly become very complex. What do you do with subscriptions that are never removed (happens all the time in dynamic environments), how do you do clustering, load balancing etc. While these things are all doable, it is very hard to do it well.
I have watched ActiveMQ for many many years now, and I have been using it almost as long. It's a good product but it has taken amazingly long for it to become somewhat solid. Even then, it only works in the very basic cases reliably; that is unreliable, non-durable, messaging. The second problem tends to be the spartan all around support for clients on various platforms - now people would come out of the woodwork to argue that there are clients for all kinds of platforms, but the problem is that they are not what the Java client is. For many clients, you still have to deal with very basic issues like client reconnects on your own (a little detail that people new to these tools always get wrong). This is not unique to ActiveMQ - HornetMQ, RabbitMQ etc. all suffer from very basic level problems when you try to do anything with reliable message delivery.
I have not mentioned one feature that I absolutely like to have; that is the ability to browse the event streams, anywhere in time, at any time, by any client, forward, or backward. Message Queues can not do this. It is possible to browse unconsumed messages in a queue, but when the most used use-case in my situation needs a topic, this goes out of the window. Also, there is no memory of previous messages for newly connected clients, other than the often used 'last message'. In any case, having an opportunity to get this kind of feature quickly becomes a 'must have' when you have experienced the convenience that it gives you. Now, I am not arguing the Message Queues should do that because that is perhaps something that queues were not really designed to do. We are approaching the other side of this blog entry with this kind of requirement.
A few years ago, we at my current job implemented something that can be described as a message queue. It is not a real message queue but it can be used for the exact same communication patterns. We implemented it with HTTP, utilizing Atom feeds for updates, with a RESTful interface.
A client can simply query for updates for the events that they are interested in. If there are new events, or updates to 'resources', you get an Atom feed as a reply. By default you may get the oldest events stored on the server, and you can browse the Atom feed for more events as you need them, or you can just zoom forward and grab the latest messages. You can tell the server to send only updates after a certain point, all of which you can track from the Atom feeds. You simply save the reference where you are in consuming the events at the client. This way, the server tracks absolutely nothing - the client decides what messages it considers consumed. This means that at any given time, you can just roll back and re-consume the same events if you like.
Because it is so simple to implement, it is also very reliable. All HTTP GETs are idempotent - can be re-tried, and you don't need transactions. You can implement transaction semantics quite easily by yourself. Say you need reliable messaging; from client's point of view this just means moving the reference point in the Atom feed once you have successfully consumed an Atom entry. If something failed, you can just come back and retry starting from the point you were at before. This is easy to implement, and you can make really sturdy consumers with simple rules.
There is no 'protocol', other than HTTP GET, PUT, POST, perhaps DELETE. You want events; do a GET for any combination of events you want. You want to publish events, just issues PUT, or POST for resource updates. You may also DELETE resources. All the events are Atom-wrapped. Simple.
I am talking about 'resources' here as liberally as I am talking about messages or events. This kind of server implementation can model things as documents or events and they can be consumed in the same manner.
For my requirements, HTTP/Atom feeding is a really nice solution. It is doable with MQs but it's not worth the hassle. The simplicity of HTTP/Atom approach is at the core of it all; no client issues, can be made reliable, browseable/queryable event feeds, scaling with typical web techniques.
Requirements
- Decoupling of publishers and subscribers.
- Reliable message delivery.
- Ability to connect, disconnect, reconnect clients without losing messages.
- Ability to shut down and restart the messaging server without losing messages.
- Ability to 'query' or 'filter' messages based on their category.
- No low latency requirement - messages delivered within 'seconds' is enough.
- No high throughput requirement - no need to scale to many thousands of messages per second.
Pub-Sub And Message Queues
Naturally, I would turn to use message queuing as a solution. What I found was that while most queue products claim to be very performant having a high throughput, none of the ones I have tried managed to deliver on reliability consistently. These products are great if you only need a best-effort, non-guaranteed, asynchronous communication channel. But sadly, when the reliability requirement is added (that is durable queues and topics) the complexity of the solutions becomes a problem. Not only that, but there are often other limitations that come into play - like performance problems even for low throughput requirements in the low hundreds of messages per second.
If you look at my requirement list, it is doable with message queues - absolutely. The problem is that it is very hard to do well the way message queues do it. The root of the problem is that durable subscriptions are tracked within the server. When the message delivery is tracked at the server things suddenly become very complex. What do you do with subscriptions that are never removed (happens all the time in dynamic environments), how do you do clustering, load balancing etc. While these things are all doable, it is very hard to do it well.
I have watched ActiveMQ for many many years now, and I have been using it almost as long. It's a good product but it has taken amazingly long for it to become somewhat solid. Even then, it only works in the very basic cases reliably; that is unreliable, non-durable, messaging. The second problem tends to be the spartan all around support for clients on various platforms - now people would come out of the woodwork to argue that there are clients for all kinds of platforms, but the problem is that they are not what the Java client is. For many clients, you still have to deal with very basic issues like client reconnects on your own (a little detail that people new to these tools always get wrong). This is not unique to ActiveMQ - HornetMQ, RabbitMQ etc. all suffer from very basic level problems when you try to do anything with reliable message delivery.
I have not mentioned one feature that I absolutely like to have; that is the ability to browse the event streams, anywhere in time, at any time, by any client, forward, or backward. Message Queues can not do this. It is possible to browse unconsumed messages in a queue, but when the most used use-case in my situation needs a topic, this goes out of the window. Also, there is no memory of previous messages for newly connected clients, other than the often used 'last message'. In any case, having an opportunity to get this kind of feature quickly becomes a 'must have' when you have experienced the convenience that it gives you. Now, I am not arguing the Message Queues should do that because that is perhaps something that queues were not really designed to do. We are approaching the other side of this blog entry with this kind of requirement.
HTTP Messaging
A few years ago, we at my current job implemented something that can be described as a message queue. It is not a real message queue but it can be used for the exact same communication patterns. We implemented it with HTTP, utilizing Atom feeds for updates, with a RESTful interface.
A client can simply query for updates for the events that they are interested in. If there are new events, or updates to 'resources', you get an Atom feed as a reply. By default you may get the oldest events stored on the server, and you can browse the Atom feed for more events as you need them, or you can just zoom forward and grab the latest messages. You can tell the server to send only updates after a certain point, all of which you can track from the Atom feeds. You simply save the reference where you are in consuming the events at the client. This way, the server tracks absolutely nothing - the client decides what messages it considers consumed. This means that at any given time, you can just roll back and re-consume the same events if you like.
Because it is so simple to implement, it is also very reliable. All HTTP GETs are idempotent - can be re-tried, and you don't need transactions. You can implement transaction semantics quite easily by yourself. Say you need reliable messaging; from client's point of view this just means moving the reference point in the Atom feed once you have successfully consumed an Atom entry. If something failed, you can just come back and retry starting from the point you were at before. This is easy to implement, and you can make really sturdy consumers with simple rules.
There is no 'protocol', other than HTTP GET, PUT, POST, perhaps DELETE. You want events; do a GET for any combination of events you want. You want to publish events, just issues PUT, or POST for resource updates. You may also DELETE resources. All the events are Atom-wrapped. Simple.
I am talking about 'resources' here as liberally as I am talking about messages or events. This kind of server implementation can model things as documents or events and they can be consumed in the same manner.
The Bottom Line
For my requirements, HTTP/Atom feeding is a really nice solution. It is doable with MQs but it's not worth the hassle. The simplicity of HTTP/Atom approach is at the core of it all; no client issues, can be made reliable, browseable/queryable event feeds, scaling with typical web techniques.
Friday, August 13, 2010
Project Euler in Scala
I had recently bought Programming in Scala book. It's a good book but you have to get your hands dirty after a while, especially because of the depth of the language itself.
Project Euler is a website with all kinds of math and computer programming problems; great for trying things out with a new programming language.
I am not attempting to pull every Scala trick in the solutions. Besides, sometimes the good old way of doing things is more readable to the 'untrained' eye.
So far I have solved the first four problems.
Here they are:
Project Euler is a website with all kinds of math and computer programming problems; great for trying things out with a new programming language.
I am not attempting to pull every Scala trick in the solutions. Besides, sometimes the good old way of doing things is more readable to the 'untrained' eye.
So far I have solved the first four problems.
Here they are:
package euler.problem1
/**
* If we list all the natural numbers below 10 that are multiples of 3 or 5,
* we get 3, 5, 6 and 9. The sum of these multiples is 23.
*
* Find the sum of all the multiples of 3 or 5 below 1000.
*/
object SumOfMultiples {
def main(args : Array[String]) {
var sum = 0
1 to 999 filter (x => x % 3 == 0 || x % 5 == 0 ) foreach(x => sum += x)
println(sum)
}
package euler.problem2
/**
* Each new term in the Fibonacci sequence is generated
* by adding the previous two terms. By starting with 1 and 2,
* the first 10 terms will be:
*
* 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
*
* Find the sum of all the even-valued terms in the
* sequence which do not exceed four million.
*/
object Fibonacci {
def main (args : Array[String]) {
var s : Int = 0
fibonacci(0, 1, x => {if (x % 2 == 0) { s += x }; x <= 4000000} )
println(s)
}
def fibonacci (x : Int, y : Int, sum : (Int) => Boolean) {
val z = x + y
if (sum(z)) {
fibonacci(y, z, sum)
}
}
}
package euler.problem3
/**
* The prime factors of 13195 are 5, 7, 13 and 29.
*
* What is the largest prime factor of the number 600851475143 ?
*/
object PrimeFactor {
def main (args : Array[String]) {
var value = 600851475143L
var factorial = 2
while(value != 1) {
if(isFactorial(factorial, value)) {
value /= factorial
}
factorial += 1
}
println(factorial)
}
def isFactorial(factorial:Long, value:Long) : Boolean =
isPrime(factorial) && value % factorial == 0
def isPrime(n:Long) : Boolean =
(2L until Math.sqrt(n).asInstanceOf[Long]) forall (n % _ != 0)
}
/**
* A palindromic number reads the same both ways.
* The largest palindrome made from the product of two
* 2-digit numbers is 9009 = 91 × 99.
*
* Find the largest palindrome made from the product of
* two 3-digit numbers.
*/
package euler.problem4
object Palindrome {
def main (args : Array[String]) {
var largest = 0;
for(x <- 1 to 999 reverse; y <- 1 to 999 reverse) {
val prod = x * y
if(prod > largest) {
val pStr = String.valueOf(prod)
if (pStr == pStr.reverse) largest = prod
}
}
println(largest)
}
}
Friday, July 23, 2010
Rescuing Nokia
The Register writes about Rescuing Nokia. The story originates from a book (promo site in Finnish) written by an old Nokia insider, Juhani Risku.
According to Juhani, Nokia has become fat, heavy with middle management bureaucracy which hinders creativity. The seed of the problem stems, according to Juhani, from incompetence of the leaders.
Amongst some of the most interesting things, the article mentions that Nokia had already been working with touch screens ten years ago, but abandoned development. Many other innovations were ready to be developed to products many years ago, but Nokia more or less ignored them, watching competition implement the features many years later. Often, it was a case of complete lack of ability to move innovations to production due to the massive and crippling effect of incompetent middle management and division leaders who had no real experience in the matters.
Juhani also states that American style business management built around short sighted arrogance and greed has hindered innovation. According to him, appointing a CEO from the USA would be a big mistake and another delay for a company that is Finnish down to the core. American style management just does not work.
According to Juhani, Nokia has become fat, heavy with middle management bureaucracy which hinders creativity. The seed of the problem stems, according to Juhani, from incompetence of the leaders.
Amongst some of the most interesting things, the article mentions that Nokia had already been working with touch screens ten years ago, but abandoned development. Many other innovations were ready to be developed to products many years ago, but Nokia more or less ignored them, watching competition implement the features many years later. Often, it was a case of complete lack of ability to move innovations to production due to the massive and crippling effect of incompetent middle management and division leaders who had no real experience in the matters.
Juhani also states that American style business management built around short sighted arrogance and greed has hindered innovation. According to him, appointing a CEO from the USA would be a big mistake and another delay for a company that is Finnish down to the core. American style management just does not work.
Subscribe to:
Posts (Atom)