Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:We have this already; it's called agile (Score 1) 299

"you sold him you knew how to do it, right?"

I never said that. You introduced the software team's prior mastery of the problem domain as a reason that agile was not appropriate to the problem. I didn't assume that -- I was thinking that both sides would have the opinion "we can just ask the human workers how they match these images", not realizing that this is a hard AI problem, or that there is still argument over whether a computer system should try to find one match or just produce a relatively short list of close matches.

I have been through training on almost a dozen different quality management approaches and systems, not all of them software- or even R&D-focused. The one thing I have learned is that there is not one process that is right for all software organizations or projects. I tend to think that there are much better ways to handle uncertainty and change risk than agile. For example, I expect storyboards and mock-ups to be more cost-effective ways to clarify the "known unknowns" than agile's sprint methodology -- which basically says to put something in code, and react to errors. I think both agile and other methodologies require good architectural decisions to avoid costly rework when a requirement unpredictably changes (an "unknown unknown"). Keeping both sides in the loop when assumptions are made or goals change is not an agile-specific process -- it is common sense and basic relationship management.

So that is why I asked you what kind of project agile is good for, and your answer seems to be that it is only good for a kind of blue-sky research that hardly ever happens. Most leading proponents of agile claim that it is good for a much wider problem domain, so I conclude that either you or they are wrong -- and if they are wrong, that speaks loudly to the agile approach itself being wrong.

Comment Re:We have this already; it's called agile (Score 1) 299

"Why would you need it? You already have a clear understandment of both process and inputs/outputs: you just need to plan, execute and deliver it."

Putting a large database in a computer, and computerizing very mental tasks like matching photographs or fingerprints, are not always well understood. The inputs are the original warehouse and human workers; the output is a computerized database that hopefully allows people to do work much more quickly or accurately or both. It verges on frivolous to say that the process is well-understood. Similarly for replacing a communication mechanism with a computerized version: The only reason to replace it is to improve on it in some fashion, and that's where the goals are usually unclear.

It seems to me that your defining-down of when agile is useful is a capitulation to Zed A. Shaw's restatement of the value of "customer collaboration" to really mean that agilistas value "bleeding clients dry" -- because you are restricting agile to cases where nobody really knows what is a good idea, making an excuse to run down tons of blind alleys by writing throwaway code in pursuit of understanding a problem, when there are vastly more productive ways to understand the goals.

Comment Re:clarity of expectations (Score 1) 299

There's a lot less unpredictability in building a house than in writing a program.

There is easily an order-of-magnitude difference in how productive different software developers within a typical organization are, and probably almost as much difference between software development organizations. Building contractors do not have that level of variability.

Hourly rates are probably also an order of magnitude different between some little town in Flyover County and San Jose.

On top of both of those, what infrastructure are you assuming for the software projects, and what performance, reliability and security requirements do you have for your software? Any of those variables can radically change what a cost-effective development approach would be.

Finally, most custom software projects involve a lot more novelty than a house. Just about anybody can figure out how many square feet of marble are needed for a countertop, but it is quite hard to estimate (within a factor of two or three) how much effort it will take to develop a feature that the developers have never tried before and that the customer can't thoroughly explain.

Comment Re: The counter-point article does not help (Score 1) 299

CMMI claims to not be a process, but it certainly dictates a lot of processes. Agile dictates an awful lot more. It doesn't tell you what you should eat for breakfast each morning, but to most people, it prescribes enough to count as a process. If a scrum master throws a fit when some developer optimizes for total work expended rather than following the order that the scrum master thinks the process requires, is it the fault of the process, the scrum master, or the developer? I would say it sure isn't the developer's fault.

Comment Re:We have this already; it's called agile (Score 1) 299

Also, your claim that "Priorities are set by the customer. It's up to him to decide what's the most useful output as of today." is a total capitulation to Zed A. Shaw's claim that that particular agile tenet is really about valuing "Instability and plausible deniability".

Comment Re:We have this already; it's called agile (Score 1) 299

If I'm replacing a warehouse full of fingerprints or photographs, and want a computerized database that will do preliminary matches, should I avoid agile? If I want a messaging system that will replace (in whole or in part) walking down the hall for a chat, inter-office memos, or email, I should avoid agile? If those are not good cases for agile, exactly what is agile good for?

Comment Re:We have this already; it's called agile (Score 1) 299

I didn't forget about cancellations due to management shuffles. Agile doesn't help there. If the customer is happy with what they have, the original AC post claimed work would stop; if the customer isn't happy, the project still gets canceled.

When I make estimates for my own work, or for people who have worked for me long enough, I can produce pretty accurate estimates that depend both on what the scope of work is and how rigorous the customer wants verification to be. I can't control what higher-level management does to those estimates, or whether the customer is happy with the estimate or with getting what they asked for (plus negotiated changes for). If the customer wants an agile process, I would advise them that it's a good way to look like you're doing something without necessarily making much progress. Storyboards and mock-ups are usually a much more cost- and schedule-efficient way to clarify goals that are not sufficiently clear.

Comment Re:We have this already; it's called agile (Score 1) 299

No, Agile focuses on each sprint ending in an output that does something -- ideally something sensible, but not necessarily something useful. If you're replacing an existing process or product, it is not useful until it becomes more functional or efficient than what it replaces, and that will probably take many sprints.

Every time I hear agilistas talk about their tenets, I am reminded of Zed A. Shaw's rebuttal to them, and how they don't have effective counter-arguments to his "what they mean" interpretations.

Comment Re:Because it was written in Seastar or C++ (Score 1) 341

Your first link doesn't say anything about compilers -- it's about cache locality and branch prediction, and how the application's architecture can make those more or less of an issue.

I watched part of the first Mike Acton video you linked, and was reminded why I hate watching videos to try to learn something: People talk too slowly and basically never organize their information for efficient understanding or consumption. I'm not about to sit through another one to find out he is mostly complaining about how slow some Javascript interpreter's general-purpose function calls are.

I will grant you that MSVC has traditionally been an awful compiler, and Clang is too new to be very uniformly good yet. As an AC pointed out, gcc does a decent job with your toy example.

Comment Re:Because it was written in Seastar or C++ (Score 1) 341

C++ compilers are pretty good at optimizing the code you write (subject to aliasing issues inherited from C, and so forth). They're not functional compilers that construct all kinds of state behind your back in hopes that it will be useful. If your complaint is that they don't do things like memoize results for you, somebody probably has a nice C++11 header that will, and most C++ developers will ask why you think a C++ compiler should memoize things without you asking.

Comment Re:Lying scum (Score 5, Insightful) 303

Hillary Clinton should know what a "server wipe" is because she was in charge of the people who were managing this, she was the head of a Federal Department, and she wants to be President. Your parents might be random schmoes with no reason to know simple computer jargon, but high-level executives in the modern world do not have that excuse.

Comment Re: Lying scum (Score 4, Insightful) 303

The way that you get everyone to follow the same laws is to enforce them fairly and predictably, regardless of who violates them. M. K. Gandhi is widely credited with saying (something like) "An eye for an eye will leave everyone blind", which exemplifies why the enforcement of this kind of thing should be as impartial as practical: otherwise it looks like partisan hits, which is corrosive to both compliance with the law and the larger political environment.

Can anything be sadder than work left unfinished? Yes, work never begun.