|
BillWoodruff wrote: Unle$$ you gotta have the moolah ... time to walk with head held high ... away ?
Hmm, I can't do private email, otherwise I would respond privately. 
Marc
|
|
|
|
|
As a consultant, all I here is one big smoking opportunity. I'm amazed the CTO is a CTO and does not understand risk.
For most of the engineering I see, and I use that term loosely, we're getting a rash of script kiddies. We also have UI people who want to do embedded systems with JavaScript. Hmmm.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
When I think of embedded systems coded in JavaScript, this comes to mind.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
that's funny
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Stable code isnt smart enough for cloud services and scrum evolving software which is hangling from one bug to the next fix. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Sounds fairly typical to me. Most CTO's are up there having become remote from their origins so have to feign knowledge of the code-verse. I try to avoid working with know-it-all script kiddies - they just f*** everything up.
|
|
|
|
|
Marc Clifton wrote: Software engineering seems dead,
Sadly I often feel that way. 
/ravi
|
|
|
|
|
I've also noticed the phenomenon you're noting, I don't believe dynamic typing the cause of it. Python, Ruby, Tcl, and Perl are more than 20 years old, and Smalltalk and various Lisps were very dynamic long before that, so the wide availability of the features they offer isn't new.
In addition, most of the architectural patterns you described work just as well in Ruby, Python, or JavaScript as they do in C# or Java. And there is certainly a ton of poorly architected, badly designed C# and Java out there.
Strong, static typing absolutely helps when it comes to building larger systems. But it won't force good engineering decisions to happen in an environment that doesn't value engineering discipline. In my experience, at least, engineering discipline and good design have been entirely orthogonal to the choice of language. I've seen well designed, well written Python applications that served a ton of users without errors or downtime, and I've worked with buggy C# applications that crashed if you looked at them the wrong way.
All of that aside, I do agree with your premise that good software engineering is becoming more rare. I believe the cause, though, is that many organizations have found that getting software in front of users as quickly as possible, even if it is buggy, is more profitable than designing it well from the start. This is particularly true for startups, but it happens often enough in large companies as well.
On the flip side of that, if you look at some more mature companies that have to serve lots of users at scale, you'll find that they use a mix of dynamically and statically typed languages, and their engineering discipline and principles are strong regardless of what language they're writing in. That kind of discipline has to be valued by leadership, and if it isn't present at the CTO level, it's unlikely it will be present at all.
For the record - I do most of my personal development these days in C#, F# and Haskell, so I'm a big fan of using a good type system. I maintain some Ruby and Python too, though, and I don't think I turn into an undisciplined maniac when I start writing code in those languages.
Edit
One more thought: there's a lot more software in the world now than there was 10+ years ago. Consequently, we need a lot more developers to create it. Perhaps the rapid expansion of the industry has made it difficult to maintain the level of engineering rigor, and also perhaps reduced the average developer ability/talent level?
Also, in disagreeing with your point on dynamic typing, I'm not trying to say that you're wrong; you seem like a thoughtful developer, so I'm sure your opinion is based on personal experience. I just wanted to offer another perspective based on experience.
modified 19-Jul-16 14:12pm.
|
|
|
|
|
I dunno about irony, but bring 'em here, and we'll approve a bit of lead-pipery in the Lounge
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Thank you, I've been waiting for the next phase of this on going saga. It will be interesting to see at what stage the CTO loses his fascination with the kiddies. Personally I would stay well out of it, I am politically incompetent so getting into a spat with a couple of kiddies with nous would be my loss.
I was asked to vet an outsourced solution a number of years ago, recommended that they not use them as there were too many different architectures in the stack. 2 years and umpteen million later the project was canned. I was delighted I had nothing to do with it and none of the sh*t stuck!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Software engineering is dead, because people found they can sell low quality software almost as well as high quality software, but without spending a lot of money for the quality. The problem is that people buy it and use it.
To defend my favorite language - JavaScript. Ability to be dynamic does not mean unstructured. I tend to use classes for six years now (yes, on ECMAScript 5.1). The problem is not the language itself, but lack of understanding foundations and concepts. Lack of theory in short.
And the problem goes deeper as university popularity (at least in my country) drops compared to private learning institutions where they prepare you to code for a month or two (mostly handling copy/pasting and slightly modifying the code without actually understanding what does it do). That's what most companies want. They have experienced people, they lack of enough people to do the dirty work.
But this is also a good news. With so many low quality software it doesn't take much to make software shines.
|
|
|
|
|
I feel for you Marc. I was in a somewhat similar situation a few years back. An app, well written, performant, stable, with both unit and integrated tests for the various end to end scenarios it would handle, was taken over by an "experienced" programmer who proceeded to disable the tests as he changed code and broke them. They didn't support his new and improved way of doing things. But required five times as much manual testing as the previous version.
He's gone, and the app is now back to its stable, performant, tested state.
|
|
|
|
|
Well, let's do a "walkthrough" ...
|
|
|
|
|
What a nostalgic post for me.
I had a contract engagement back in '97 where I architected and implemented a distributed database system for an inbound call center that insisted that they track 2.3 million names and their orders on the back of MS Access. I sharded the data across 8 database instances to maintain some sense of usability.
When the contract was up and the work was completed, I conducted knowledge exchange with the staff and CIO. The system was highly modular, and the whole OO bag of tricks. The system had sub-second response times for all transactions.
The CIO told me at the end of the session that he couldn't in good conscience hire me back because I produced something that was out of the realm of his staff, whose normal dev environment was FoxPro. Therefore they would be at my mercy to maintain anything I produced.
I have been leery of working with any person or group who doesn't understand the plumbing.
|
|
|
|
|
As a sewage worker, life can be pretty mucky, but finding a Moltres under Wall Street really made my day!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
(><<) (5)
Revive
Hints:
1. Tasty as hell!
2. Best food for long programming sessions (except BACON!)
3.
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
modified 19-Jul-16 8:51am.
|
|
|
|
|
steer
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
0B 0W
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
dummy
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Again 0B 0W
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
I left with 9 possible solutions, and your hint put me on the right one, but just remembered that tomorrow I will be occupied from 10:00 to 22:00, so I can't deliver it...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
That's okay
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
BACON!!!!!!!!!!!
sorry, I couldn't resist
|
|
|
|
|
at least 1W! 
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
