I think I have failed to understand the point. “Choose design over architecture.” ok, great, but then they basically redefine design as architecture? If I evaluate my current development practice, I have no idea how I would determine if I’m choosing design or architecture.
I can just imagine some consultant coming in and announcing that I’m too focused on architecture and rebutting them by saying “no, no, that’s design” and having them reply, “oh, it’s ok then.”
I read the head of the article in detail (say first 5 paras) and then skimmed the tail. What I got was that “waterfall”/“architecture” is being used as a strawman of sorts for very rigid design specs. What is being proposed is a “agile”-like method where you make software more organically but constrain yourself with modular code.
I think in practice, if done in a supportive environment, this means lots of refactoring, but better code and code -> user fit in the end.
Instead of a 20 line function, the engineer breaks up functionality into six smaller methods that each play a little part
I don’t disagree with the theme of the article, but it’s the little details like this that make it seem like author believes his own words too much.
20 lines? I guess in maybe something like OCaml, but even Python that can be a stretch. Naming all those smaller methods is likely harder than it looks and making methods out of something the language provides is wasteful.
Quite a stretch for C. Replacing four lines of inline code can often result in four lines to set up the function call. In order to get meaningful reduction, you have to replace eight lines with a function call, but then that function is too long, requiring further reduction to even simpler calls. Before you’re done, the number of functions will exceed the number of lines in the original.
Like most style guidelines, I really dislike this one when taken as an absolute rule. Sometimes a function just has to do twenty different things in sequence. For god’s sake don’t split it arbitrarily into doTheFirstThreeThings(), doTheNextThreeThings(), etc. for the sake of function length! If there’s not a reasonably clearly correct way to split it up, consider that the correct thing to do may be to not split it up and keep the guideline no more than guidelines.
A question for people more familiar with user stories…
So, I think it’s obviously useful to have things of the notion “A user who is a foo does bar so that they can baz”.
That said, some of these seem kinda…silly and low level, I suppose. Like the story for justifying a logo.
What’s a useful level of detail for these user stories? Somewhat more grumpily, to what extent are they just for justifying another job slot in the org chart?
Probably not that useful by themselves, but if your dev process is user story based, then you need a story to get things done. Deciding what needs a story and what doesn’t probably wastes more time than going through the motions. Of all the many incarnations of inefficient make work processes, user stories probably aren’t that bad.
I think I have failed to understand the point. “Choose design over architecture.” ok, great, but then they basically redefine design as architecture? If I evaluate my current development practice, I have no idea how I would determine if I’m choosing design or architecture.
I can just imagine some consultant coming in and announcing that I’m too focused on architecture and rebutting them by saying “no, no, that’s design” and having them reply, “oh, it’s ok then.”
I read the head of the article in detail (say first 5 paras) and then skimmed the tail. What I got was that “waterfall”/“architecture” is being used as a strawman of sorts for very rigid design specs. What is being proposed is a “agile”-like method where you make software more organically but constrain yourself with modular code.
I think in practice, if done in a supportive environment, this means lots of refactoring, but better code and code -> user fit in the end.
It would probably end up something like this: If the consultant says it, it’s design. If the dev says it, it’s architecture.
I don’t disagree with the theme of the article, but it’s the little details like this that make it seem like author believes his own words too much.
20 lines? I guess in maybe something like OCaml, but even Python that can be a stretch. Naming all those smaller methods is likely harder than it looks and making methods out of something the language provides is wasteful.
I have plenty of 1- or 2-line methods in my Scala code. Breaking a 20-line method up doesn’t sound so unreasonable.
Quite a stretch for C. Replacing four lines of inline code can often result in four lines to set up the function call. In order to get meaningful reduction, you have to replace eight lines with a function call, but then that function is too long, requiring further reduction to even simpler calls. Before you’re done, the number of functions will exceed the number of lines in the original.
Like most style guidelines, I really dislike this one when taken as an absolute rule. Sometimes a function just has to do twenty different things in sequence. For god’s sake don’t split it arbitrarily into
doTheFirstThreeThings(),doTheNextThreeThings(), etc. for the sake of function length! If there’s not a reasonably clearly correct way to split it up, consider that the correct thing to do may be to not split it up and keep the guideline no more than guidelines.A question for people more familiar with user stories…
So, I think it’s obviously useful to have things of the notion “A user who is a foo does bar so that they can baz”.
That said, some of these seem kinda…silly and low level, I suppose. Like the story for justifying a logo.
What’s a useful level of detail for these user stories? Somewhat more grumpily, to what extent are they just for justifying another job slot in the org chart?
Probably not that useful by themselves, but if your dev process is user story based, then you need a story to get things done. Deciding what needs a story and what doesn’t probably wastes more time than going through the motions. Of all the many incarnations of inefficient make work processes, user stories probably aren’t that bad.