|
From Code Complete (2nd ed)- Steve McConnell[^]
* Steve McConnell: "In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That's unfortunate because if you buy into any single methodology 100 percent, you'll see the whole world in terms of that methodology. In some instances, you'll miss opportunities to use other methods better suited to your current problem. The toolbox metaphor helps to keep all the methods, techniques, and tips in perspective--ready for use when appropriate."
* This quote is from 2nd ed but the 1st ed (1993) also has this same paragraph, just slightly changed for style.
|
|
|
|
|
I wanted to try and make a parallel with marriage, but ...
|
|
|
|
|
Rage wrote: I wanted to try and make a parallel with marriage, but ...
That's because marriage is an anti-pattern. So this sentence, applicable to software consulting:
Quote: That's unfortunate because if you buy into any single methodology 100 percent, you'll see the whole world in terms of that methodology.
for marriage, would read:
Quote: That's unfortunate because if you buy into any single methodology 100 percent, you'll see the whole world in terms of OTHER METHODOLOGIES.
Latest Article - Web Frameworks - A Solution Looking for a Problem?
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
raddevus wrote: if you buy into any single methodology 100 percent,
So I'm curious. How would you define "methodology"? What common methodologies exist? Are we talking BS like the non-existent waterfall methodology which was coined as a joke to which we now have Agile and flavors like TDD, Code First, Schema First, etc.?
Because none of those methodologies have any real substance to them other than "tailor it to your needs" which is, of course, the ultimate methodology. So it's not a "toolbox metaphor", sadly, it's another methodology. The "toolbox methodology."
Apologies if I sound snarky, I don't mean to, I just get frustrated with things that are common sense but have to be couched in buzzwords for management to adopt. Oops. Snarky again. 
Latest Article - Web Frameworks - A Solution Looking for a Problem?
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I was somehow reading it as "the JavaScript method" and "the C# method" and "the [insert language/DB/library/framework] method", so if you decide to go full C# you'll never think of using JavaScript (which may fit some problem better than C# because of its dynamic nature).
Of course if you keep your options open like that you'll still need knowledge about all those options and that's difficult...
Perhaps Python would be better at solving my current problem, but I don't know anything about Python and getting a Python programmer on board would be very impractical to say the least.
That's my problem with this "toolbox" thing anyway.
|
|
|
|
|
I'm thinking of this type of definition of methodology (as described by a dictionary):
wordnik dictionary: A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods
I think McConnell's point is that when you lock into things so strongly -- simply because someone has said it is the correct way and simply because that someone seems to have authority -- then you cut yourself off from other solutions because you've narrowed your focus.
Of course this is difficult because if you don't narrow your focus, you end up swallowing the ocean and not having any type of process (guiding methodology) at all and that is a failure too.
I just find that people in IT (and maybe all endeavors) point at a thing and say, "that is how it is done" and then they are done.
But as implementors we often find that there are other challenges those methodologies do not and cannot address and that is when you have to open your eyes to reality.
modified 5-Mar-19 16:36pm.
|
|
|
|
|
raddevus wrote: But as implementors we often find that there are other challenges those methodologies do not and cannot address and that is when you have to open your eyes to reality.
Having spent the best part of the last two years maintaining and debugging code that was written over the past 10 years by geniuses(I use the word both in the sense of admiration as well as with gritted teeth) the one thing I have taken away from my experience is be consistent and try not to be too clever when dealing with edge cases.
Easier said than done I realise.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: Having spent the best part of the last two years maintaining and debugging code that was written over the past 10 years by geniuses
I've been there too. Having to maintain OPC (other people's code) is a great, yet painful way of really learning the necessity of process, valid design and good code.
GuyThiebaut wrote: the one thing I have taken away from my experience is be consistent and try not to be too clever when dealing with edge cases.
Great advice.
|
|
|
|
|
raddevus wrote: I'm thinking of this type of definition of methodology (as described by a dictionary):
That's funny - I forgot about the article I wrote 2003: What Is A Framework?[^]
where I use that same definition. Reading the definition again struck the "that sounds familiar" bell, and a google search on CP found my 16 year old article. 
Latest Article - Web Frameworks - A Solution Looking for a Problem?
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: Reading the definition again struck the "that sounds familiar" bell, and a google search on CP found my 16 year old article.
|
|
|
|
|
raddevus wrote: I think McConnell's point is that when you lock into things so strongly -- simply because someone has said it is the correct way and simply because that someone seems to have authority -- then you cut yourself off from other solutions because you've narrowed your focus.
That is too simplistic. Seems more like something that a 'guru' says at at weekend retreat.
In the real world there are many more concerns. For example if I need to support legacy code that has evolved over 10 years, I absolutely do NOT want to see that the company has allowed every programmer the freedom to implement anything they want in any way that they want. Doing that means that after 10 years it will be an absolute mess with very high maintenance costs.
And I don't want to have a new startup with that philosophy either. In that case the team needs to deliver a product and then maintain that product. That is the goal and the vast majority of the time for the vast majority of business domains choosing a very narrow set of technologies, of any consistent sort, will allow the goal to be achieved. And mandating those technologies is the way to insure that developers on that team do not start experimenting (which has nothing to do with goal.)
raddevus wrote: "that is how it is done" and then they are done.
Because it works.
I don't care if my house was built with very newest type of nails. I do very much care that it gets built, gets built for a reasonable price and that it doesn't fall down on my head when once I move in.
There is absolutely one assurance that new technologies bring - that those using them do not know how to use them effectively and do not know what problems they will introduce much less how to insure those problems do not come up in the first place.
raddevus wrote: But as implementors we often find that there are other challenges those methodologies do not and cannot address
As a long time implementer that is never the problem. Problems that do exist are things like very, very poor requirements. Like requirements that don't even solve what the customers need (I worked a contract were 2/3 of the customer base couldn't use the product out of the gate.)
Another problem is absolutely no one does business sizing. Often people don't even know what that means. They have no data, they don't know the size of the market, they don't know how the customers will even use the product. I worked at one place where a 'consultant' insisted that the product needed to support millions of simultaneous users where in fact a monopoly on the entire world wide market usage for the product domain would never have generated that much traffic (and no it was not a new product domain - it wasn't going to grow.)
Then there are developers, almost all of them in my experience, who simply have no conception of error handling and enterprise production support. This leads to things like ignoring exceptions entirely, eating them or handling all exceptions like one single limited expected exceptions. And then either logging stuff that is useless or not logging at all. I have been dealing with that problem continuously for 30 years.
Then there are problems that crop up because users don't know how to use the system, and people have found ways to hack the system to get it to do what they want but no one ever documented what the system should be doing much less what was allowed and not allowed. I delivered a reporting system into a loan management company which immediately broke everything they were doing because there was literally a SQL injection hole that the support people learned how to take advantage of to do part of their work that they really needed to do.
|
|
|
|
|
I work according the one true methodology: Money First. 
B.T.W. My wife uses the same methodology.
|
|
|
|
|
100% agree. 40 years in the software development business, from industrial to finance, and I have never seen a pure waterfall methodology used. And these days, the ones I see doing agile have no idea how their methodology ties back to the Agile Manifesto. One example of many - when I see adults standing in a scrum meeting like 3rd graders giving a report, I cringe. That is not what "stand up" even means in that context. If you cannot control your speaking time, or know when to take an issue offline, you really do not belong in that job. Much like business analysts have no place managing software development projects.
If we make choices from a recipe book ("Today's Hip Software Methodologies"), then where exactly are we applying our knowledge, skills, and abilities as engineers? Methodologies and design patterns are good resources to evaluate, and draw from them whatever best works for a project, but they are no substitute for the software engineer/architect who can actually think.
|
|
|
|
|
I have that book and read it from cover to cover. It's usually highly recommended (that's why I bought it), but I remember thinking at the time that this was nothing but page after page of obvious platitudes.
In other words, everything he wrote about seemed pretty obvious to me as a developer who had already worked in that field for more than a few years by that time. But maybe that's the point--these are lessons learned from experience and the target readers are the newcomers, so they don't have to make the same mistakes to learn from them...
Same with books on design patterns. Generally I feel like this is all stuff I've seen and done before to various degrees; I just never knew they had formal names assigned to them.
|
|
|
|
|
dandy72 wrote: these are lessons learned from experience and the target readers are the newcomers, so they don't have to make the same mistakes to learn from them...
That implies that the "newcomers" can learn, and looking on how the QA works lately... I start to doubt it 
Note: I am not implying a generalization that all people in new generations are dumb. Only that a bigger part of it than before is it (or at least if not dumb, lazy without limits).
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
dandy72 wrote: In other words, everything he wrote about seemed pretty obvious to me as a developer
The secret may be that he is trying to leak this information out to the dev managers. 
|
|
|
|
|
Direct problem with my boss. According to him, I have to develop every. Single. Feature in a branch. Even if it takes me literally 5 minutes to develop & test something, I have, according to him, create a branch for that sucker to merge it into master later. WTF...
|
|
|
|
|
As a 30+ year software professional, it's super hard for me to sympathize with this viewpoint. Branches in modern source control are so lightweight and easy -- and this was done in git and Mercurial specifically to support the methods you're being asked to follow.
It's not your boss you are upset with. You just don't care for safe, solid development methodology.
|
|
|
|
|
Except when something's not needed, there's no point in doing that. I work on my code alone, for starters. Second, most of the stuff I develop is highly self-contained, no impact on the program at large, especially no possibility for regression. Under those circumstances, there's no point in branching.
I care for the result. The right tool for the job. If a change takes me literally 5 minutes to stabilize (=no regression), then following the same protocol as for big, potentially breaking (or rather likely breaking) changes is cargo cult.
|
|
|
|
|
An even older version of this truth is: "When all you have is a hammer, everything looks like a nail".
|
|
|
|
|
Sounds like MVVM.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
kind of, he says to use everything as a tool. something to get the job done. some tasks are better done with AWK some in Java, others with REBOL.
|
|
|
|
|
raddevus wrote: That's unfortunate because if you buy into any single methodology 100 percent, you'll see the whole world in terms of that methodology. In some instances, you'll miss opportunities
Sigh...even then that wasn't reasonable.
Less so now.
Complexity insures that no one can do everything. Is some company supposed to use 50+ different programming languages just in case they can save a nickel on one method. That of course doesn't account for the problems with supporting that, integrating with it, hiring for it and administering it.
raddevus wrote: The toolbox metaphor
Certainly does. I have tools in my tool box I have never used. I had one tool that I probably bought 10 years ago and I never even opened the box until this last year. And another tool that I have used no more than 3 times and it failed completely every time at the very task it was supposed to solve.
|
|
|
|
|
for a shave and a haircut.
He tells the barber that he can't get all the whiskers off his face because his cheeks are so wrinkled. The barber gets a little wooden ball from a cup on the shelf and tells the old cowboy to put it inside his cheek to spread out the skin.
When the barber's finished, the old cowboy tells the barber that it's the cleanest shave he's had in years, but he wanted to know what would have happened if he had accidentally swallowed that little ball.
The barber replied, just bring it back in a couple of days like everyone else does.
Yes I'm bored
I'm currently unsupervised, I know it freaks me out too!
JaxCoder.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
