171–180 of 201 posts
It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…
Earlier quoted context omitted.
I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances. Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spe…
You have successfully solved the problem posed, but it was not well-stated. In a real-world scenario, it is important not just to identify which of the 10 ideas is most promising, but to defeat the null hypothesis that the programmers should be fired and no idea should be pursued. After all, to choose the best of 10 bad ideas is to have failed as an economic enterprise. In order for a business to be investable, it is…
The first, as I believe you presume, is that the business is looking to develop a revenue-generating product. I agree that Continuous delivery, quick iterations, late-binding requirements (a la Behavioral Driven Design), and rigorous testing are not a strong candidate for this problem within the context of big business, and I can point to a handful of systems where this approach did not work well.
However, the second interpretation is that a big business has ten internal projects to increase their efficiency. In this case, return on investment is relatively easy to calculate, but requirements are usually nebulous and thus estimates are by necessity high-variance.
I think the subset of agile techniques I described (as well as cross-functional teams, high customer involvement, and exploratory testing) are well suited to this problem because they, as a collection, allow a business to receive value quickly and allow the business to "fail fast" in lean startup parlance.
Are you building embedded software? The agile approaches aren't, collectively, well suited for that domain (though I'd argue pair programming and cross-functional teams aren't a bad idea here.) It's not going to work for games. But for internal software and Now, as for a few things you mention.
* The programmers are not responsible for calculating return on investment. However, does an extensive requirements gathering mission with months of meetings going to be cheaper when the costs of meetings (in lost productivity and wages) is calculated? In my experience, these documents end up being works of fiction, on which aggressive estimates are produced upon pressure of management. Then, the costs overrun (especially considering that nobody accounted for the lost productivity of the customer) because the estimate was based on business need rather than reality. Then, features are dropped and technical debt accrues, leading to a system that is hard to maintain and is scrapped after five years of frustration when the customer starts again. At least, this time they know what they don't want. I don't think that works.
* I think that is the situation that leads to the "red" projects that you mention. However, you speak about early days of software where most software was profitable. However, I've seen and heard the horror stories of multi-million (and Billion!) dollar projects from the 80s and 90s. While http://calleam.com/WTPF/?page_id=1445 mentions recent studies, I remember seeing studies that 2/3rds of projects fail in the 80s and 90s as well.
So, most software wasn't profitable then (at least in terms of internal projects) and they aren't now.
However, I'd argue that the collection of techniques above allow a project to fail faster and cheaper if managed correctly.
If we were to put it into a methodology, here it is:
1. Determine return on investment if X can be automated. How many hours are saved? How many fewer people are needed to do the same job? What percentage better forecast can this project create (estimated)
2. Use some sort of behavior driven development to get a basic sense of the complexity of the system needed. If the complexity and ROI don't match up, stop here. You've lost a minimum amount of money.
3. Start prioritizing which pieces would provide the most business value for the least complexity cost. Build the first of these pieces, elaborating on the BDD done in step 2. Write this with good tests, so that the system can be extended with a reduced fear of later regression.
4. Demo to customer. Does this fit their needs? Is additional complexity exposed? Does this provide value? This is the next cutoff point. If the system appears to be more complex than thought, or if the team is unable to provide the business value anticipated, stop the project and re-evaluate or shelve.
Everyone gets together and does a retrospective with a question to continue, an honest look at what worked and what didn't, and a set of things to try to fix the problems of the first iteration.
5. Repeat steps 3 and 4 until the software either sufficiently meets the business need or the project is ended early due to a fatal flaw. Always be willing to ask if this is the appropriate time to declare the system "done for now." ___
Now, this won't work in most major corporations for a variety of political reasons, but to me this seems to be a better system than the traditional corporate project structure from my experience in both successful and unsuccessful IT projects.
In my experience, these methodologies are best described as cultish. The form of religion but not the power. Here's my methodology. * Figure out what the software does, what the business cares about, and what the users care about. * Figure out what it kinda sorta needs to be under the covers * Write prototypes of the technically gnarly bits. * Flesh out the prototype and start writing integration/functional tests for…
I'm only asking because I've seen "in my experience" sermons delivered by fresh-out-of-college kids one too many times, and have become wary of the phrase.
Earlier quoted context omitted.
Isn't that one of those methodologies ;)
Yeah that was a little bit optimistic about the powers of Agile for me, but I think the thing that Agile gets right is that we all have to operate under the uncertainty of the scope of software projects. In that sense it's not a methodology for estimating the complexity of a software project but a way to start working without that. Perhaps the biggest reason this keeps causing problems is that companies have no good…
However, until you establish reality, all the estimates in the world aren't going to help much. And most customers cannot estimate reality until they are actually in the process.
I'm not saying Agile is a silver bullet -- it can go wrong in many ways, and it's not appropriate for every situatoin. However, it's the best we have for its niche.
What is interesting is why this relates to software more than, say, ditch digging or gardening.
I would say that is because software involves dealing with the most complex situation imaginable as effectively as possible. In other situations, a person only has to mobilize some of faculties, in software, a person has to mobilize all of their faculties - or at least much more of a certain type. But this shows how different people's abilities are at the limit. Not just different in extent but different in kind.
Earlier quoted context omitted.
Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have…
> Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." If that's the actual answer, then anything else is just obfuscating the truth. Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers never m…
There are three possible reasons for an answer of 'I don't kmow'
1. Something is unknowable 2. The person being question has insufficient expertise to discover the answer 3. The person being questioned hasn't really thought about it.
You appear to be assuming that 1 is always the reason.
And that's crazy. Software delivery is at least 50% design/problem solving - and those aer neither completely predictable or repeatable.
To me a software methodology works if it _improves_ delivery. If the result with the methodology is more predictable, and less likely to go horribly off the rails than if you'd used a different methodology (or none at all) then it's a good methodology.
Looking for something that can perfectly transform any human requirement into code, in a predictable manner, is just silly.
The problem here is that he defines "works" as "Deliver a predictable or repeatable software development process in and of themselves." And that's crazy. Software delivery is at least 50% design/problem solving - and those aer neither completely predictable or repeatable. To me a software methodology works if it _improves_ delivery. If the result with the methodology is more predictable, and less likely to go horribl…
To me, Scrum really helps me focus on what's important now, and not waste too much time on potential future problems.
Earlier quoted context omitted.
Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally b…
This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody. Managing ego and heart is harder than managing a project i think.
Gerald Weinberg
http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_...
http://www.codinghorror.com/blog/2008/01/no-matter-what-they...