|
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
|
|
|
|
|
|
That would feel like being pulled down a railroad track?
I'm currently unsupervised, I know it freaks me out too!
JaxCoder.com
|
|
|
|
|
Only if you are a Ruby on Rails developer, poor sods 
|
|
|
|
|
/ravi
|
|
|
|
|
As in: open VS with a tiny solution I created yesterday in VS2017 - three projects, two "just started", one a VS2013 utility project that has worked for years.
Opens fine. Click on .CS file in different assembly and it locks up completely. 27% CPU usage (so that'll be a whole core looping plus some other tasks) ignores minimize, close, any click at all.
Repeatable, fails every time. Quick check in PSPad and the .CS is fine - a dozen lines of code or so, nothing complex.
Quick check and VS is solidly up date.
So, I'll try a repair installation. 6GB download later (fortunately at 5MB/sec) and it's downloaded. Installing. Lets grind to a halt, shall we? Up to 3% now, after only ten minutes ...
Is it always like this? VS used to be relatively reliable (as in you could rely on them not to fix the bugs but at least it didn't fall over). I'm so close to saying "sod it" and going back to VS2013 - it just worked!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Well ... it fixed it, at the cost of throwing away all my settings (indentation, screen layout ...)
Annoying though, it's probably too late to get started on much now.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Well ... it fixed it, at the cost of throwing away all my settings (indentation, screen layout ...)
Fortunately these can be exported as separate settings. Over the years I've learned just how important those settings can be.
My editor rules get imported on all of my machines, but I keep separate screen layout settings per-computer, as not all of my machines have the same number of monitors/resolution.
|
|
|
|
|
OriginalGriff wrote: Annoying though, it's probably too late to get started on much now.
But at least you have a line for your status meeting: "Watched VStudio 2017 update itself: half day."
|
|
|
|
|
"Who's the more toolish? The tool, or the tool who uses it?" -- Obiwan after some gin.
VS 2010 continues to rock.
|
|
|
|
|
I dislike VS2015/17 because they induce seizures with all the crap that flashes on/off the screen as you code. I can't f*ckin stand that crap.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
