Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.
In the 1950s, test pilots were being killed at the rate of about one a week[1]
61–70 of 172 posts
Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.
In the 1950s, test pilots were being killed at the rate of about one a week[1]
Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…
It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a fracture because you didn't look past the swelling to the root cause of the pain. This is nothing new, consultants have been loathed for this very reason for a long time now.
That was me telling you how to do your job. If you wanna know more, google it. If ya got offended, have a nice day!
Earlier quoted context omitted.
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…
There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a frac…
And, for what it's worth, the C-level types loved the project too. What I did was replace a wooden peg with a modern prosthetic and upset the guy who was selling wood oil for conditioning the peg and the guy who sold the leather straps [1].
edit: That said, sure, it'd have been less stressful if I worked in the politics up-front. I said as much. But I've done it that way enough to know it would inevitably have compromised the system. And my post was a response to "why aren't the systems better?".
[1] and him, only because he couldn't see past the loss of the peg-strap business to see the gain of business making, maintaining and adjusting straps for the modern prosthetic.
Then again, I doubt these guys do this since it's all marketing.
Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…
This is why I'm far happier now consulting to startups than to large corporations or the govt.
Earlier quoted context omitted.
This was posted on HN so that we can make fun of it, and I think we're right to do so. You can be as wishy washy as you like about different situations requiring different processes, but have you ever seen somebody successfully isolate software engineering from coding and put them in sequence?
Waterfall is actually considered the very best model for software development, when the requirements are known up front in excruciating detail. An average project experience around 25% change in requirements. Hence waterfall is highly unsuited for the majority of projects, since it does not handle requirement changes well. However, in a few areas such as aeroplane control software, space shuttle software and similar,…
Actually, this is refreshingly honest compared to the "agile" methodologies. Having worked with plenty of supposedly agile consultants I can tell you they basically do waterfall it's just their cascading stupidity starts with code and then wanders around writing unit tests until the client is tapped out. At least this is doing some actual user interface design and usability testing. Then again, I doubt these guys do…
One can only imagine what actually happens in communication once they have a client. If the marketing is a complete lie, then I can't imagine the company itself can be trusted.
I actually know Clark Valberg, the founder of Epicenter Consulting, and did some work with him a few years back; he's a great guy. You guys can criticize him all you want, but he actually cares. We should direct our efforts towards the bloodsuckers, not the people giving blood.
I'm sorry, but the people who claim the one true method is keeping the programmers locked in the basement without real world input or feedback are the bloodsuckers.
Earlier quoted context omitted.
This was posted on HN so that we can make fun of it, and I think we're right to do so. You can be as wishy washy as you like about different situations requiring different processes, but have you ever seen somebody successfully isolate software engineering from coding and put them in sequence?
Waterfall is actually considered the very best model for software development, when the requirements are known up front in excruciating detail. An average project experience around 25% change in requirements. Hence waterfall is highly unsuited for the majority of projects, since it does not handle requirement changes well. However, in a few areas such as aeroplane control software, space shuttle software and similar,…
Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…
I admit to liking waterfall myself (it suits the kind of work I do) and if well done by competent people and for certain types of project its the way to go ...