Become a fan of Slashdot on Facebook


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:Scrum Was Never Alive (Score 1) 371

If you have most of those prerequisites -- everyone agrees on a process, you have a good architecture, and the project staff are highly motivated and get along -- then basically any process will work. If you say that scrum only works when you have those, it does not speak well of scrum. The purpose of real engineering processes are to manage projects where not everyone sees eye to eye, you have a variety of per-worker productivity levels, and you probably have uncertainty about what you need or what is possible.

Comment Re:Scrum is fantastic! Do it today! (Score 1) 371

Every halfway-decent development methodology makes a big deal about breaking things down so they can be accurately estimated. If you look at the SEI's Personal/Team Software Processes (PSP/TSP), which are basically the waterfall method on steroids, one of the biggest objectives near the start of the project is to try to break tasks down into chunks no bigger than a day.

Obviously, when you break things down that much, you will be wrong a lot, but once you get a few projects under your belt, you should be pretty close for work that is similar to things you have done before -- and your estimates should be pessimistic about as often as they are optimistic, so the large number of smallish individual estimates averages out to a not-so-bad overall schedule error. (Another benefit is that when your work units are that small, you should have a pretty good estimate of project progress.)

Comment Re:So AMD called their Hyperthreading a CPU core? (Score 5, Informative) 311

AMD's CPU architecture has a similar purpose as hyperthreading -- to share hardware resources between what looks to the OS like independent cores -- but the tradeoff is different. Intel's hyperthreading approach only works to cover memory latency, because the hyperthreads share so many physical resources (I think basically everything except register files and hyperthreading-related state). AMD's is somewhat different in that each "module" has two independent integer ALUs, register files, and L1 data caches. The module has one L1 instruction cache, one L2 data cache, one FPU, and one instruction fetch/decode unit.

But AMD has always been pretty up-front about this architecture. There is maybe a cause of action against resellers who package the AMD chips into systems and do gloss over which aspects each "core" shares with another core, but AMD publicly presented the core-vs-module distinction well before the chips were released.

Comment Re:Something something question in headline equals (Score 4, Insightful) 568

I've done software engineering in the past. It was slow and expensive, parts of it were tedious, and parts -- particularly fallout from the fact that (fairly) rigorous software engineering is rarely done -- involved more hassle than they should have been. Even at that job, most of what I did was more traditional software development than engineering, and all my other software-developing jobs have been far from the level of rigor and care that I would call engineering.

However, when I did software engineering, with clearly defined requirements and interfaces, with an explicit architecture and functional decomposition of the software, with carefully planned and executed verification and validation, the results were definitely higher quality than you would get from less time- and labor-intensive methods. Most of the time, cheaper methods are acceptable and worth the increased chance of defects. Flight systems, healthcare, other safety-critical systems, and financial computing usually, and justifiably, prefer to pay for more rigor and higher quality.

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.

Let's organize this thing and take all the fun out of it.