Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Can anyone point me towards any references that attempt to formulate an economics of software development? In my own research, I discovered a book by Barry Boehm on this, but it seems very awkward and theoretical.
Dependency Structure Matrices seem to offer something worthwhile. Carliss Baldwin has used these in some work on modularization, boundaries, and transaction costs. A lot of it comes off as just common sense, though.
Also, economists have developed something called Behavioral Economics. Is there a "Behavioral Software Engineering" that addresses cognitive biases in developers or groups of developers?
Here's an interesting looking reference:
http://www.amazon.com/Knowledge-Sharing-Software-Development-Comparing/dp/3639100840/ref=sr_1_1?ie=UTF8&s=books&qid=1232979573&sr=1-1
Before Hal Varian became the Chief Economist at Google, he had worked on the economics of information technology at Berkeley, although he did not focus on software development per se. Nevertheless I would recommend a look at his paper on the more general topic from 2001. You can find a more complete list of his research work on his website. Hope that helps.
Software as Capital wasn't a waste of time, though you won't find any math in it and it reads like a PhD thesis because it started as one.
Another review.
I think that what you're looking for might fall under a sociology of software development... sociologists study all modern subjects, and from there you will no doubt find references to an economics of software development if there is one.
Facts and Fallacies of Software Engineering by Robert Glass has some dollar amounts associated with some activities (or, at least, percentage of total budget). Don't know if that helps at all, but it's something.
Several years ago I taught an "Economics of E-Commerce" course using Varian's book INFORMATION RULES. His idea of lock-in, though, leads the reader almost towards a drug-addict model of purchaser behaviour and exploitation. This book is more of an economics of e-business than an analysis of the software development process.
In terms of actually making software, there are ideas in the Mythical Man Month well worth knowing about.
The "Applied Information Economics" approach of Douglas Hubbard could be part of what you're looking for. If we assume software development is (often|always|sometimes|???) about supporting decision making by providing (better|more accurate|more up to date|whatever) information, then AIE helps as it's a technique for quantifying the value of better information. Read Hubbard's book How to Measure Anything for a good overview of the idea.
Also, the book Software By Numbers by Mark Denne and Jane Cleland-Huang provides a model for managing software projects by using something they call the "Incremental Funding Methodology". IFM is based on decomposing software projects into features based on the business value created, rather than decomposing them along technical boundaries. They then use a series of calculations based on Discounted Cash Flow (DCF), Net Present Value (NPV), Internal Rate of Return (IRR), etc. to show when in the project lifecycle the project will reach self-funding status, when it will reach "breakeven" and when it will generate a real positive cash return for the organization.
You might also find the Capability Cases book of interest. It doesn't strictly deal with any economic issues in detail, but it's an approach to software specification which attempts to more clearly map software capabilities to business strategy and business issues.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Almost every one of my programming classes has made use of UML, but none have really explained when or where it might be used in a professional setting. Is it done for every single file in a project, or is there some rule of thumb of when you might want to use it? Also, is it more commonly done by hand (which I've always dreaded) or using some sort of generator?
This question is very good example of opinion-based and very broad question with no real problem to solve behind it and no one correct possible answer
Certainly in the amount of millions of software developers there are some who learned to use UML and do use it. And there are some who either did not learn to use UML or just don't use it for whatever reason
I recall that in the pre-agile era it was believed that no "big" software can be realized without thorough analysis and modeling phase and no "big" software contract can be signed if the business documents don't include some UML-style pictures
And in some countries it is still true and government-owned agencies declare what kind of documentation software contractor must provide, and for some of the requirements an UML picture is the good form
See also:
Wikipedia: Rational Unified Process (RUP)
Wikipedia: Software requirements specification
Programmers: Writing a Software Requirement Specification
So there are UML believers, UML skeptics and even UML haters, it depends on ... things.
I'm UML believer
and so is for example Mr. Kenji Hiranabe from Change Vision, Inc the company behind Astah UML modeling tool and he says
...Is modeling obsolete? Is UML dead? I don't think so. In this article...
as foreword to article Modeling in the Agile Age: What to keep next to Code to Scale Agile Teams
my favorite guideline is what The Guru said in an interview with Mark Collins-Cope for the Objective View magazine on Sep 12, 2014
Grady Booch, creator of the Unified Modelling Language (UML):
"The UML should be used to reason about alternatives. Put up some diagrams. Throw some use cases against it. Throw away those diagrams then write some code against you best decision. Repeat (and refactor)"
How you finally evaluate "..UML...commonly...real world.." depends on what you want to see and which software development best practices you adopt in your own work
It depends on your role, in most developer roles you will rarely, if ever, have to use it. I can see it being useful if you are designing something though, like a new database structure, or architecting a new system or application.
It can be useful for lead developers, architects, or IT managers in the design stages of the application for communicating ideas to the business folks as well as passing on a plan for the development team that will be building it out.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I was reading about the necessary metrics for SCRUM and I couldn't find 'Defect Leakage' listed in there. This is the case even with the papers published by Jeff Sutherland.
I was wondering if there is any reason behind not considering this as an important metric in Agile SCRUM. Does anyone know?
Scrum is a minimal process improvement framework. It very deliberately doesn't talk about any metrics beyond meeting the sprint goal.
If your team find defect leakage a useful metric in helping them improve then they are, of course, allowed to use it. If the management outside of the Scrum team find defect leakage a useful metric - then they're perfectly free to use it too.
Scrum doesn't define the metrics you should use. It allows you to use any that you find effective.
There are no metrics in SCRUM. This doesn't mean you can't have metrics, it just means that SCRUM doesn't mandate them nor tells you what you should do in this case, hence why you aren't finding anything of the sort.
Since we're talking about SCRUM, one usual mindset to this is to ask ourselves:
is it useful? Does this <activity,metric,task> have a big value?
why do i want to do this? What will i get from it?
So instead of looking for the answer, i suggest you answer yourself that.
(PS: my boss asked me to is not the greatest motivational answer)
If you take a look at the Scrum Guide you can see that Remaining Work is only metric mandated as part of the Scrum Framework. As long as you can monitor Remaining Work you are at least looking at that one "thermostat" for your project.
Does that mean that you should not look at anything else? Heck no... as long as you continuously monitor your metric usage and watch for negative impacts on the team and organisation you can monitor whatever you like. Some teams require to do time-sheets for financing while other like to monitor mean-time-to-resolution or build quality. Although after looking up "defect leakage" I would question its usefulness.
p.s. Scrum is a noun and not an anachronism and so does not need capitalised
Scrum should not be set-up as an excuse for bad code or for defect leakage. If there is leakage, that means there will be items being added back into your backlog and unhappy clients. Most teams that I talk to using scrum also try to use techniques from xtreme programming, like test-driven development, junit tests, automated regression test scripts. No matter the tools, you should have QA resrouces booked 100% on the team, who are ultimately accountable for their processes around issue management and the quality of the deliverable that is deployed at the end of each sprint.
Another thought: if defect leakage is a metric expected by the enterprise, you could consider treating it as a criteria on a user story for sprint 0. But, if it's not important to the project or enterprise in general, you probably won't get it from the team during execution, or the team might implement it when problems arise in an adhoc, tactical manner.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I remember reading an article saying something like
"The number of bugs introduced doesn't vary much with different programming languages, but it depends pretty much on SLOC (source lines of code). So, using the programming language that can implement the same functions with smaller SLOC is preferable in terms of stability."
The author wanted to stress the advantages of using Functional Programming, as normally one can program with a smaller number of LOC. I remember the author cited a research paper about the irrelevance of choice of programming language and the number of bugs.
Is there anyone who knows the research paper or the article?
Paul Graham wrote something very like this in his essay Succinctness is Power. He quotes a report from Ericsson, which may be the paper you remember?
Reports from the field, though they will necessarily be less precise than "scientific" studies, are likely to be more meaningful. For example, Ulf Wiger of Ericsson did a study that concluded that Erlang was 4-10x more succinct than C++, and proportionately faster to develop software in:
Comparisons between Ericsson-internal development projects indicate similar line/hour productivity, including all phases of software development, rather independently of which language (Erlang, PLEX, C, C++, or Java) was used. What differentiates the different languages then becomes source code volume.
I'm not sure if it's the source you're thinking of, but there's something about this in Code Complete chapter 27.3 (p652) - that references "Program Quality and Programmer Productivity" (Jones 1977) and "Estimating Software Costs" (Jones 1998).
I've seen this argument about "succinctness = power" a few times, and I've never really bought it. That's because there are languages (e.g., J, Ursala) which are quite succinct but not (IMO) easy to read because they put so much meaning into individual symbols.
Perhaps the true metric should be the extent to which it is possible to write a particular algorithm both clearly and succinctly. Mind you, I don't know how to measure that.
The book of pragmatic Thinking & Learning points to this article.
Can a Manufacturing Quality Model Work for Software?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to start Agile practices in a team. I'm assuming the information is available for free online about how to specifically carry it out.
Online I can locate the manifesto, the alliances and corporations involved but where is the actual central guide or root instruction set about how to do it? (Maybe the practices themselves are more ethereal or subjective than I expect and it's found in multiple places?)
Edit to summarize solutions:
Agile is a concept so that's what's to be found online about it. However specific processes or methods of Agile development have been created like Scrum and Extreme programming to provide concrete solutions to teams who want to adopt Agile and reap its proposed benefits. Find the shoe (or method) that fits best. Maybe create it.
If looking for solutions online to implement Agile development in your organization or for your project, seek out the specific methods too and decide among them.
There are numerous Agile methods.
Not one. And nothing definitive on something like "Agile". That's like a definitive guide to "Honesty".
Read this for one Agile method that some folks like: http://www.controlchaos.com/old-site/Scrumo.htm
Alos, there are numerous non-Agile methods. They'll all have a form similar to this: http://en.wikipedia.org/wiki/Waterfall_model
I agree with S.Lott. There are lots of Agile methods, not the one Agile method per se. Likewise I wouldn't know any central guide which covers All You Ever Wanted to Know About Agile.
I would actually recommend a book here. The one I found gave a pretty good introduction into how to go agile was O'Reilly's "The Art of Agile Development". Mind you, yeah, it is a book and therefore costs money, but not so much that it wouldn't be worth it if you really want to learn something.
There's nothing like specifically carrying out Agile. It's a bunch of methods and ways that you can adapt (or choose not to adapt). Some of them are more important than others, specific methods (like Scrum) define a couple of must-follow rules, whereas you can just as well pick what you think works best for you and see how it turns out.
I would actually recommend starting at one point with a good definition of Agile (the one at Wikipedia seems fine, along with a list of Agile methods and practices) and reading up on all the methods and practices from there. There will be googling involved.
Here is a good resource to learn about Extreme Programming which is another agile methodology.
Here's a downloadable book by Henrik Kniberg on Scrum and XP from the Trenches which describes in detail how his team did Scrum. When we implemented Scrum it was useful to have an in-depth look at what another team had found effective.
There is no definitive resource for all agile methods - as there is so much diversity in the methods.
The people that came up with the word "agile" didn't actually have that much in common - so it's not as though there's an "international headquarters of agile"... ;-)
It depends which one you want to know about: Scrum or XP or Crystal or one of the other methods... some of them are quite different from each other...
For Extreme Programming - the original XP material (and many of the experts) wrote it up at http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Scrum: The Scrum Alliance is pretty much the definitive place for Scrum http://www.scrumalliance.org/
Crystal is by Alistair Cockburn so look for stuff by him. I don't know much about how to do crystal, but Google likes this: http://alistair.cockburn.us/Crystal+methodologies+main+foyer
Don't start out by reading a bunch of different methods you haven't tried out and mixing together the bits you like - a mistake that's far too common. That results in random chaos.
Best way to start:
Look at some agile methods
Pick the one you think is most practical to adopt in your circumstances.
Try doing it by the book for a while - say for at least a month.
After you've been doing it for a while, you can get the team together to run a retrospective to decide what to improve - or what to try instead.
Recommendation (assuming you don't have experienced help on hand)
Scrum is pretty easy to get going. You can set it up in about 2 days if you're familiar with the basics.
Maybe after you've done scrum for a while you can start phasing in more of the XP practices. In any case, scrum doesn't have anything to say about technical things like the code, testing or refactoring - so once you've got the scrum basics down, you could start rolling in some XP practices. I think Test-Driven Development is the first one to start with.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I read a lot of books about what practices work well or not in software development.
And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.
Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.
ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.
That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.
Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).
In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.
The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.