What exactly is a learning curve?
And why is it wrong to use the term "steep learning curve" for something which has high entry barriers and takes quite some time to get into?
As to the why-ness of this question:
The terms are used often and inconsistently on Stack Overflow
I myself have been confused by it
Mostly the newbies are confronted with these terms when they for example ask questions like "what's the best php development framework"
It's a curve of time versus proficiency.
Steep for hard is wrong because it'd mean that you get very proficient in very little time
proficiency
| __
| |
| | Proficient in little time (steep = easy)
| |
|_/____________
time
proficiency
|
| Proficient in lots of time (gentle = hard)
| __
| /
|__________/___
time
See wikipedia.
"steep learning curve" is a buzz-phrase that doesn't have any actual meaning. It used to mean that you'd make quick progress. "Over time, the misapprehension has emerged that a "steep" learning curve means that something requires a great deal of effort to learn..."
Conclusion: people who use the phrase don't know that it's unclear. You should get details from them on what specific things are hard to learn and get past the buzz-phrases and platitudes.
(from unix.rulez.org/~calver)
(source: rulez.org)
This (very unserious) diagram subscribes to the steep == "hard to climb" interpretation, for anyone keeping score. Emacs. So true. ;-)
I've generally understood it to have more to do with the amount of time allotted to learning, and what you have to learn in that period of time. If you have only a short amount of time in which to learn something, your learning curve is going to be much steeper than if you had a longer amount of time to learn the same amount of material. So a steep learning curve IS difficult because it means you're trying to cram six months worth of learning into three weeks, or whatever.
More material in the same amount of time would produce the same curve.
from Widipedia:
The term learning curve refers to the
graphical relation between the amount
of learning and the time it takes to
learn.
The term "steep learning curve" is often wrongly used for things which need some time to wrap ones mind around. Also here on Stack Overflow I've seen it used wrongly many times and hence this Question and my own answer to it.
In fact a steep learning curve is given, when it is relatively easy to start of with a new skill/technique/...
it means that the relationship between "learning progress (y)" and "time invested (x)" is greater than 1.
It's a battle of intuitiveness. On one hand, you've got "steep=hard to climb" association, on the other hand you have "time on the horizontal axis" convention (but "proficiency on the horizontal axis" isn't "wrong", just "less popular"). So, IMHO it's not a matter of "right" vs "wrong" but rather "intuitive" vs "more intuitive".
I think that "steep=hard to climb" will win, because it appeals to anyone who at any point in their life has climbed a stair, as opposed to the x-y curve which even people trained in mathematics sometimes mix up.
There are a few possible interpretation of "learning curve", but a fairly natural one would be "time elapsed" on the X axis and "knowledge gained" on the Y axis. A steep curve, in that mapping, would imply that you gain a lot of knowledge, fast.
The only interpretation I can think of where "steep" is the same as "hard" is where you map "knowledge gained" on the X axis and "effort expended" on the Y axis and that is not a very natural mapping.
A "learning curve" originally had total elapsed time [or total cumulative units manufactured/learned] on the X axis and the time required to produce/learn a single unit on the y axis. Your first unit always takes more time than the 100th or 1,000th. The "steepness" of the curve depends on how fast you get good at producing/learning a thing. Learn quickly and you have a "steep" curve; slowly and you have a flat curve.
I agree that the uninformed have morphed the original meaning of the term, but to be accurate steep is easy. People get upset because those of us who paid attention to using language correctly in school rarely get to take part in this type of evolution.
Learning curve is the rate at which knowledge can can acquired. A new developer on a complex system will likely experience a steep learning curve as they will have a lot to learn before they can become productive. By implication an experienced developer may experience a shallow learning curve if they are familiar with a system.
The acquisition of knowledge does not always imply understanding. In some cases a developer may not need to absorb a lot of system detail but may need to understand underlying designs before they can be productive. This can take time but does not imply a steep learning curve.
In practise understanding and knowledge go hand in hand. Most developers will always be on a learning curve of some sort but will also be using new knowledge to forge a deeper understanding of the systems they are working as well as the tools and practises they are using.
It's true that "steep learning curve" should mean "easy" given the origin of the learning curve as a graph of measured performance as a function of time, and that the proper expression for a hard-to-learn-task should be "gradual learning curve". But it's perfectly natural that "steep learning curve" should have come to mean "hard" given that a) most people have never looked at an actual learning curve, and b) "steep" implies "difficult" whereas "gradual" implies "easy".
This is how languages evolve, and it would be utterly futile to try and change the general usage of this term now. And, in any event, I could care less about the whole issue (see how you still knew exactly what I meant?).
Level of difficulty is not a factor. A learning curve depicts the length of time to acquire a proficient skill set or high level of comprehension. The description will vary based on the test subject that the curve is applied to. While one can certainly say that the learning curve for acquiring proficiency of an application such as MS Notepad would be steep, another application for the curve would be the length of time individual test subject take to acquire such proficiency. The learning curve for acquiring proficiency of MS Notepad is generally steep, but it may be steeper for Mary than it is for John.
I think the key is to first understand what the curve is being applied to
Related
Not sure if this question is related to software development, but I hope someone can at least point me in the right direction(no, not that direction..)
I am very curious as to how Blizzard achieve such a balance of strategic/tactic forces in their games? If you look at Starcraft 1 or now 2, each race have unique features that sort of counterpart other unique features of other races and all together create a pretty beautiful(to my mind at least) balance.
Is there some sort of area of mathematics that could help model these things? How do they do it basically?
I don't have full answer but here is what I know. Initially, when game is technically ready the balance is not ideal. When they started first public beta there were holes in balance that they patched very fast. They let players (testers) play as is and captured statistics of % of wins per race and tuned the parameters according to it. When the beta was at the end ratio was almost ideal: 33%/33%/33%.
I've no idea how Blizzard specifically did it - it might have just been through a lot of user testing.
However, the entire field of CS and statistics dedicated to these kinds of problems is simulation. Generally the idea is to construct a model of your system and then generate inputs according to some statistical distribution to try to understand the behaviour of that model. In the case of finding game balance, you would want to show that most sequences of game events led to some kind of equilibrium. This would probably involve some kind of stochastic modeling.
Linear algebra, maybe a little calculus, and a lot of testing.
There's no real mystery to this sort of thing, but people often just don't think about it in the rigorous terms you need to get a system that is fairly well-balanced.
Basically the designers know how quickly you can gather resources (both the best case and the average case), and they know how long it takes to build a unit, and they know roughly how powerful a unit is (eg. by reference to approximations such as damage per second). With this, you can ensure a unit's cost in resources makes sense. And from that, it's possible to compare resource gathering with unit cost to model the strength of a force growing over time. Similarly you can measure a force's capacity for damage over time, and compare the two. If there's a big disparity then they can tweak one or more of the variables to reduce it. Obviously there are many permutations of units but the interesting thing is that you only really need to understand the most powerful permutations - if a player picks a poor combination then it's ok if they lose. You don't want every approach to be equally good, as that would imply a boring game where your decisions are meaningless.
This is, of course, a simplification, but it helps get everything in roughly the right place and ensure that there are no units that are useless. Then testing can hammer down the rough edges and find most of the exploits that remain.
If you've tried SCII you've noticed that Blizzard records the relevant data for each game played on B.Net. They did the same in WC3, and presumably in SC1. With enough games stored, it is possible to get accurate results from statistical analysis. For example, the Protoss should win a third of all match-ups with similarly skilled opponents. If this is not the case, Blizzard can analyze the games where the Protoss won vs the games where they lost, and see what units made the difference. Then they can nerf those units (with a bit of in-house testing), and introduce the change at the next patch. Balancing is a difficult problem - a change that fixes problems in top-level games may break the balance in mid-level games.
Proper testing in a closed beta is impossible - you just can't accumulate enough data. This is why Blizzard do open betas. Even so the real test is the release of the game.
I'm trying to estimate the hours required to build a group of 5 simple children's games in Flash. They will include such things as having kids drag and drop healthy food items into a basket; choosing the healthy and unhealthy food items by marking them in some way; etc.
I have no experience building games in Flash, but I have programmed in Flex and Actionscript. How many hours do you estimate for this project?
While your ActionScript background will help, I find Flash to be a VERY different experience from Flex and that proficiency in one environment does not translate well.
Is there a compelling reason not to use Flex? I think you would likely be much more efficient.
That aside, the mechanics of a simple drag and drop game could be put together fairly quickly. There are some good examples of basic drag and drop around. It can be a little tricky to get the mouse coordinates right if it is your first time.
That aside, there are other hidden costs you need to remember. Connecting infrastructure for example. Are the games connected in some way? Is there a running score or persistence that might imply authentication? Is there a story?
Also, If your forte is programming, don't underestimate that challenges of obtaining or creating art and sound assets.
Before you can estimate the time you'll need to break down what the games do. In other words, you'll need to write up very clear and definite requirements. You may even need to write up specifications. Once you've analyzed what the software should do, the estimate will also take a while - one part for example is figuring out whether there's already software that does what you want.
In my opinion, the best way you can possibly estimate a programming project, especially one in a technology you don't understand, would be to apply the Use Case Points methodology. Basically you break the project up into use-cases (what the users are trying to do) and actors (the user types and the system itself) and then list a few team and environment factors (how big an issue is code re-use, how familiar are you with the lanaguage, etc.) Studies have shown that it's more accurate for inexperienced developers than estimating based on features alone.
A google search for "use case points estimate" reveals many useful links. This explanation of the methodology seems to do a good job explaining how it works, though I've not read the entire thing. This worksheet will help when you're ready to start listing points.
In my very short time working in the programming field, I've seen two extremes:
Projects where little to no planning was done and thus become maintenence nightmares.
Projects that are perpetually in the planning stages and don't move from there.
It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?
In my own personal experience, I have found that 'decisions' are my bottle neck.
If this is the case, then :
List all your design options
Pick an option(s) (pick a few if you can't decide on one)
List the risks of the best option(s)
For each risk, brainstorm a solution, then design a conclusive proof of concept and write it.
If your proof of concepts proves it will NOT work, then toss that option, and pick another one.
A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)
If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.
And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.
Initial planning should be roughly O(log n) where n is expected total development time.
If you have to push in a week, sketch something on a napkin.
If you have a month, the first day is for initial design.
If you have a year, spend a week.
This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).
Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.
If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.
I think it depends on 2 factors:
The length of the project
Is it a 1 week project?
Is it a 1 year project?
Or somewhere in between?
The risk of the changes being introduced in the project
Are they architectural in nature, potentially affecting a lot of the original code?
Or are you simply adding a new feature?
Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.
There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:
The 2 biggest mistakes you can make in a design are:
1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation
Finding the happy medium between these 2 is the key to successful design and planning.
Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:
how much detail can you actually get from any user/sponsor and from this specific group
how much detail does your current team need (technical/business specific skill levels)
how open are your sponsors/users in helping during the development (how agile of a team do you have - does it include the sponsor/user?)
how good are you are identifying gaps
A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).
The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)
For example, can an experienced coder with limited C#.NET experience be successfully paired with an experienced C#.NET coder with the secondary aim of getting the former up to speed with C#.NET?
Absolutely. Sharing knowledge is one of the points of pair-programming (along with the useful dynamic of having one person type for a bit and the other review as they do it).
In my experience, it's one of the most effective ways of doing so - and allows the less experienced coder still to usefully contribute (it takes less experience to review what an expert is doing and make sensible comments/interventions than to do the entire job).
That depends on the personal chemistry between them. If the more experienced programmer is willing and able to share his knowledge, and let the less experienced programmer participate in the development through writing code and discussions, I would say that it is a very efficient way of learning.
Yes, I find good pair programming is always two way, it's essentially a piece of social engineering masquerading as an IT innovation.
Yes, this will work. If 1) the programmer with limited experience is receptive to learning C# and 2) the other programmer is willing to teach C#.
When the skill mismatch is high, then it does become more of a teacher/student relationship. This isn't bad, but can waste time of the skilled person.
However, even if it's impractical or a waste, it can be very useful to have a very occasional pair session! Even if the student is overwhelmed or it's awkward, sometimes it's useful for "students" to see how people of top level work and think. It helps give them an idea of the problems/skills/methods of high quality work. Think of it as a high school student visiting a research laboratory. It's a waste for the pro scientists to teach the high school student, but the 1 hour visit can help focus the student and give them a glimpse of the ultimate goals...
I remember why I chose Emacs as my editor. I just happened to sit near an expert user, and literally rudely peering over his shoulder I watched him rearrange and navigate code super-quickly. I only watched for less than a minute and I never talked to him.. he may have not even noticed I was watching! But I was floored, and decided to learn Emacs. Ten years later I still don't have as much skill as that expert, but I don't regret my decision to change editors, since I got a glimpse of what was possible.
Personally, I think that would work well and is one of the goals of pair-programming but how successfully will depend on the two programmers. If programmer 1 (the one learning C#) was putting in some extra time to truly get up to speed and programmer 2 (the other one) has the patience and desire to teach it should be good for both.
You can certainly do this - we've done it in the past. But you have to accept that you trade off the "code quality" benefits against training benefits. There's no free training ride, I'm afraid.
It works to some extent. Usually it's one leading the other... so it's not much pair programming in that sense.
It depends heavily on the experienced coder's skill to teach and the other coder's skill to learn quickly.
Yes, but only if the better person is patient and willing to teach and the worse person is willing to learn. I've pair programmed with people not as good as me and it was tedious, but I think they learnt from it. I've pair programmed with people that are better than me and I certainly learnt from it. Depends on the people really.
It can be effective with the following caveat: You must switch partners.
I've actually been in this situation and, if the gap is large, it can be very taxing for both members of the pair. Best to switch partners after a few hours, with the time varying according to your tolerance and the size of the gap. If that option isn't available, mix in some solo programming.
There's a saying that a team's strength is as good as its weakest link. Pairing the strongest one with the weakest one has traditionally been the best strategy because the weakest learning from the strongest potentially ensures most amount of learning. If there is a worry of the strongest being uninterested, then replace the strongest with someone who'd really be the strongest.
It all depends on the personality of the developers there is no hard and fast rule.
One thing that is certain is that the experienced developer will be less productive when working with an inexperienced developer. I personally think there needs to be a good match of abilities when pair programming. It is however a very good way of getting inexperience developers up to speed.
Although its a good idea but practically it may not be useful. To train somebody you can organize training and assign mentor who can help and guide. The mentor can assign work from the real project and may monitor.
Pair programming should be between relatively experienced people, if you want to get the benefits of this concept. In my view pair programming with an inexperienced person will have loss of productivity and not sure how much the person will pickup when somebody is constantly checking on him. Assigning a task and giving chance to develop it independently and then review it will provide good self learning.
Yes, but the approach to make it effective may not be clear at first. The task that is being pair programmed on should be the task of the less experienced programmer (We will call him Michael). I would also have Michael start the pair programming session so as to explain what the objective of the session is. This approach puts Michael in the drivers seat where the more experienced programmer (We will call him Bill) will serve more of a mentoring role.
Typically Bill will either take or be given more complex tasks to work on. This approach allows Michael to work on tasks that are more suited to his experience level. I would recommend switching off at 30 minute to hour intervals at first such that Michael can get used to the process of giving someone else control. You can slowly shorten these switch offs to 15 minute intervals or whatever works best for the two developers.
I think that the final results you get depend on the guys that are doing this. In this case, you'd probably end up with one leading the other (and where the other is just paying attention to understand the language features the first one is using).
It depends on how much skills impedance mismatch we're talking about.
Two good programmers in different languages can grow-up quickly with it, obviously at the cost of a little slowdown of the one expert in the current project's language.
If the difference is too big (for example, a veteran and a rookie), instead, it might be preferable to start with some other kind of approach, to avoid the risk of getting highly counterproductive.
Always beware the extreme pair programming !
I come from a fairly strong OO background, the benefits of OOD & OOP are second nature to me, but recently I've found myself in a development shop tied to a procedural programming habits. The implementation language has some OOP features, they are not used in optimal ways.
Update: everyone seems to have an opinion about this topic, as do I, but the question was:
Have there been any good comparative studies contrasting the cost of software development using procedural programming languages versus Object Oriented languages?
Some commenters have pointed out the dubious nature of trying to compare apples to oranges, and I agree that it would be very difficult to accurately measure, however not entirely impossible perhaps.
Most all of these questions are confounded by the problem that individual programmer productivity varies by an order of magnitude or more; if you happen to have an OO programmer who is one of the gruop at productivity x, and a "procedural" programmer who is a 10x programmer, the procedural programmer is liable to win even if OO is faster in some sense.
There's also the problem that coding productivity is usually only 10-20 percent of the total effort in a realistic project, so higher productivity doesn't have much impact; even that hypothetical 10x programmer, or an infinitely fast programmer, can't cut the overall effort by more that 10-20 percent.
You might have a look at Fred Brooks' paper "No Silver Bullet".
After poking around with google I found this paper here. The search terms I used are Productivity object oriented.
The opening paragraphs goes on to say
Introduction of object-oriented
technology does not appear to hinder
overall productivity on new large
commercial projects, but it neither
seems to improve it in the first two
product generations. In practice, the
governing influence may be the
business workflow and not the
methodology.
I think you will find that Object Oriented Programming is better in specific circumstances but neutral for everything else. What sold my bosses on converting my company's CAD/CAM application to a object oriented framework is that I precisely showed the exact areas in which it will help. The focus wasn't on the methodology as a whole but how it will help us sold some specific problem we had. For us was having a extensible framework for adding more shapes, reports, and machine controllers, and using collections to remove the memory limitation of the older design.
OO or procedural offer to different way to develop and both can be costly if badly managed.
If we suppose that the works are done by the best person in both case, I think the result might be equal in term of cost.
I believe the cost difference will be on how you will be the maintenance phase where you will need to add features and modify current features. Procedural project are harder to have automatic testing, are less subject to be able to expand without affecting other part and is more harder to understand the concept part by part (because cohesive part aren't grouped together necessary).
So, I think, the OO cost will be lower in the long run compared to Procedural.
i think S.Lott was referring to the "unrepeatable experiment" phenomenon, i.e. you cannot write application X procedurally then rewind time and write it OO to see what the difference is.
you could write the same app twice two different ways, but
you would learn something about the app doing it the first way that would help you in the second way, and
you may be better at OO than at procedural, or vice-versa, depending on your experience and the nature of the application and the tools chosen
so there really is no direct basis for comparison
empirical studies are likewise useless, for similar reasons - different applications, different teams, etc.
paradigm shifts are difficult, and a small percentage of programmers may never make the transition
if you are free to develop your way, then the solution is simple: develop things your way, and when your co-workers notice that you are coding circles around them and your code doesn't break nearly as often etc. and they ask you how you do it, then teach them OOP (along with TDD and any other good practices you may use)
if not, well, it might be time to polish the resume... ;-)
Good idea. A head-to-head comparison. Write application X in a procedural style, and in an OO style and measure something. Cost to develop. Return on Investment.
What does it mean to write the same application in two styles? It would be a different application, wouldn't it? The procedural people would balk that the OO folks were cheating when they used inheritance or messaging or encapsulation.
There can't be such a comparison. There's no basis for comparing two "versions" of an application. It's like asking if apples or oranges are more cost-effective at being fruit.
Having said that, you have to focus on things other folks can actually see.
Time to build something that works.
Rate of bugs and problems.
If your approach is better, you'll be successful, and people will want to know why.
When you explain that OO leads to your success... well... you've won the argument.
The key is time. How long does it take the company to change the design to add new features or fix existing ones. Any study you make should focus on that area.
My company had a event driven procedure oriented design for a CAM software in the mid 90's created using VB3. It was taking a long time to adapt the software to new machines. A long time to test the effects of bug fixes and new features.
With VB6 came along I was able to graph out the current design and a new design that fixed the testing and adaptation problem. The non-technical boss grasped what I was trying doing right away.
The key is to explain WHY OOP will benefit the project. Use things like Refactoring by Fowler and Design Patterns to show how a new design will lower the time to do things. Also include how you get from Point A to Point B. Refactoring will help with showing how you can have working intermediate stages that can be shipped.
I don't think you'll find a study like that. At least you should define what you mean by "cost". Because OOP designing is somehow slower, so on the short term development is maybe faster with procedural programming. On very short term maybe spaghetti coding is even more faster.
But when project begins growing things are opposite, because OOP designing is best featured to manage code complexity.
So in a small project maybe procedural design MAY be cheaper, because it's faster and you don't have drawbacks.
But in a big project you'll get stick very quickly using only a simple paradigm like procedural programming
I doubt you will find a definitive study. As several people have mentioned this is not a reproducible experiment. You will find anecdotal evidence, a lot of it. Some people may find some statistical studies, but I would examine them carefully. I am not aware of any really good ones.
I also will make another point, there is no such thing as purely object oriented or purely procedural in the real world. Many if not most object methods are written with procedural code. At the same time many procedural programs use OO methodologies such as encapsulation (also call abstraction by some).
Don't get me wrong, OO and procedural programs look and are different, but it is a matter of dark gray vs light gray instead of black and white.
This article says nothing about OOP vs Procedural. But I'd think that you could use similar metrics from your company for a discussion.
I find it interesting as my company is starting to explore the ROWE initiative. In our first session, it was apparent that we don't currently capture enough metrics on outcomes.
So you need to focus on 1) Is the maintenance of current processes impeding future development? 2) How are different methods going to affect #1?