22,224 reputation
658102
bio website
location Toronto, Canada
age
visits member for 4 years
seen Aug 3 at 15:25

"Enterprise" developer/architect with an EE background and experience/interest in:

  • Microsoft .NET / Visual Studio
  • Delphi
  • VB/VBA (although I try to forget)
  • SQL Server, SQL CE
  • Web Services (SOAP, WSE, WCF)
  • Web Applications (WebForms, MVC, JS)
  • Embedded Systems (HCxx, PIC, etc.)
  • UI Design & Data Visualization
  • Project Management
  • and probably a bunch of other things...

Aug
12
awarded  Popular Question
Aug
11
awarded  Guru
Jul
31
comment Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
@Dunk: Architecturally, yes, presentation is generally encapsulated and kept separate from other concerns. But I said product development, not coding. Product development is a process that involves multiple skill sets, business departments and stakeholders, and the UI is the part that (almost) all of them will want to get involved with. Accordingly, if it's done in a business silo, then you'll usually end up with an unusable product, and if it's done in a technical silo, you'll usually end up with a design that at best requires terrible hacks, or at worst can't be implemented at all.
Jul
29
answered Why doesn't the HTML\DOM specification allow hyperlinks to set an accept header?
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: I, too, hear this about projects in highly-regulated industries. I've also worked on some, and my experience agrees with 6-9 months as the practical limit; one went on longer, and after about 1 year it totally derailed because the PMs couldn't figure out how to manage all the changes. In my experience, these projects you are referring to typically stick to the regulatory issues as the requirements, and let the rest fall into "implementation", whereas formal iterative processes would have a much larger "design" scope - larger, but also more spread out over time.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: The only projects that don't require iteration over the design are very small projects. In real-world projects lasting more than a few man-weeks, the realities of implementation (including integration/interop, library issues/limitations, not to mention changes in the business and operating environment) make that moot. In 11 years, working for or with 6 different companies, I have never seen a project where the design did not change in some way. Usability testing alone pretty much breaks that model.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: And that last thing you just described is, in fact, the broken Waterfall model. Models like Spiral and RUP do permit iteration on the requirements and design. The "design everything up front" strawman waterfall model can work... on projects less than 1 month long. But then again, so can any process, including no process at all.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: Waterfall was, in fact, described as entirely non-iterative. The term was first coined by Royce and he used it specifically to describe a non-iterative process, which is broken for software development. You can verify this if you look up Royce. It's more recently been used to describe, basically "anything non-Agile", sort of like how "nosql" means "anything not SQL", but that really only serves to confound the issue, since every process is different.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
To put it another way, Agile methods design features up front, waterfall tries to design systems up front (and fails). Even the "good waterfall" methods like RUP concede a certain amount of iterative design.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: It's a common misconception that Agile methods eschew "design up front". What they eschew is "big design up front", heavy emphasis on the "big" - as in trying to design everything about a 10-million LOC system before writing a single line of code. There is supposed to be a design phase (called "planning") at the beginning of every sprint, and it is supposed to follow a particular architecture or a set of architecture guidelines. The number of projects that requires everything to be designed up front is far smaller than most business executives would like to believe.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: And, incidentally, genuine waterfall projects shouldn't be run through any team or process - they shouldn't exist, period, because the model is irreparably broken. See my comments in other parts of the question - there are "working" waterfall-like models, such as Spiral and RUP, but true waterfall (AKA "traditional project management" or manufacturing project management) simply doesn't work.
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
@svidgen: Huh - when did I say that "waterfall projects should be run through an agile team or process"? I thought I said the exact opposite. As far as what causes the quality/deadline issues, that's covered in a number of other questions here, but in brief: (1) Agile estimation methods aren't suitable for L- or XL-sized projects; (2) Agile methods rely on adjustable scope and don't work with fixed-scope projects; (3) Agile requirements management depends on a feedback loop throughout a product's lifetime, not a "requirements phase". There are other issues but they won't fit in a comment.
Jul
29
answered In general, should an organization adopt a single methodology or decide on a per-project basis?
Jul
29
comment In general, should an organization adopt a single methodology or decide on a per-project basis?
"a mix of processes that work best" - ah yes, the good old water-scrum-fall, the conceit of non-technical business managers thinking they can cherry-pick the parts that look good or easy and discard the rest. Don't get me wrong, there are other valid processes (like the RUP), but most companies that do what you're saying haven't even tried to follow the process precisely, and usually the dev team limps along pretending to be agile while still bending over to meet definitively non-agile fixed-scope deadlines.
Jul
29
comment Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
@Graham: It depends on who you're working for and what their management is like. It's more typical of non-technical management, and especially non-technical management that loves deadlines and is accustomed to seeing half-finished products ship.
Jul
29
comment Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
It really sounds like you're talking about prototyping to me, because if you're still throwing designs away then that's what you should be iterating on - not actual code.
Jul
29
comment Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
This is the only answer I can identify with. The others don't even seem to be considering the possibility that good product development doesn't break down cleanly into "UI" and "back-end". It's a question that only a newbie programmer or project manager would ever ask, and not one that an experienced programmer or PM should deign to answer at face value. The very idea of asking which should be "done first" stinks of waterfall.
Jul
26
comment Why is polling accepted in web programming?
Besides which, trying to run an application with millions of users on a single machine is just a terrible engineering practice, whether or not it manages to scale up to the load. What's your availability SLA? What's your business continuity plan? I don't want to be the one maintaining that system and getting paged in the middle of the night because the one server that powers everything died, or because something just happened to slow down or crash and not come back up. That's the "big picture" - not some nonsense about caching and a contrived example about news readers (we all know RSS).
Jul
26
comment Why is polling accepted in web programming?
@LieRyan: Caching has nothing to do with it. It's a non-sequitur. Regardless if you've set up your headers to cache at your own server, a proxy server, or the client, you're just wasting resources if your cache timeout is different from the poll interval. And it's irrelevant because it costs less to maintain a websocket for 3 hours than it does to have the client poll every 10 minutes and get a 304 back. Native Android/iOS apps also support websockets so that's not an argument either. Maybe the scale argument was valid 5 years ago but it isn't anymore. Deal with it.
Jul
26
comment Why would programmers ignore ISO standards?
@user61852: For example, IP over avian carriers is legitimately defined by the IETF. Nobody's actually using it, and you'd be a fool to try. XHTML is also a standard, but you won't find many people using it anymore.