|
I think modern day software development is very much easier than it used to be. Easy languages have replaced difficult ones. The internet has all the answers a click away. All the difficult stuff (calling conventions etc., COM binary standards etc.) (punched cards too!) has disappeared leaving you to focus much more on what you want to do, and less on getting it to work somehow. RAM and storage is limitless, processor speeds forgiving of appalling performing amateur code. Cloud elasticity even more so.
All the algorithms we learnt in the old days are in a framework somewhere done for you. Worst yet, everyone is just an integration developer hooking different open-source projects together which usually have some cute avatar or logo - usually for some inane website. Worst insult is they're probably doing it in JavaScript. 
Too stupid to learn a proper language? You don't have to, use node.js and never get involved with that nasty threading stuff.
Harder and more complicated, my foot.
Regards,
Rob Philpott.
|
|
|
|
|
If you consider it a natural part of your job to spend half of your time getting to learn new tools, new "frameworks" really doing exactly the same things as those you already know, just in a different way, then you of course have no difficulties. The essential thing is to understand the tools, not the problem, and that is a simple matter. At least if you are a member of the tribe in force.
If you are focused on the problem, at the end user level, trying to solve it using a bewildering set of ever changing tools, frameworks and whathaveyou, and none of the solutions you could have provided five years ago are invalid today because they do not fit today's frameworks (or, do you remember the term 'programming paradigm'? If you refer to that in public today, you immediately declare yourself as coming from the stone age).
I once had a vision of attacking the customers complex problems, providing good tools for helping him understand how to solve it. After 35+ years in software development, we still spend most of our resources on how to handle our own tools, rather than the customer's problems. And some of the tools that I know from personal experience to be really useful to understand the customer's problems have been disqualified, replaced by other tools aimed at the software developer's problems, not at the customer's.
Maybe I today can write software more easily - if I ignore the end user. As I see a lot of software developers do.
|
|
|
|
|
1 year later.
Do to how popular and extensive plugins used for YAML 3x Spectre, now being to difficult to manage, we have create a new language to make deploying your YAML easier.
|
|
|
|
|
I'm not sure if this the correct answer, or even if the question is correct.
It depends on our will/enjoyment of learning I would say.
As we gather our years of experience, we see a lot of patterns, and we start to recognize them in other languages/ parts of the software, etc.
So in general writing software becomes easier
Add to that the capabilities of some dedicated IDEs complementing our skills.
But for someone who despises learning, branching out, new patterns may really seem hard/complex etc.
|
|
|
|
|
What flaw?
Well, for those of us who have been doing this for a while, the longer the while the more likely we'd be getting involved in every more complex development (no - I can't prove that).
In addition - like, well, for example, science, the easier staff is sort of done and is off-the-shelf. You don't need to be a glass-blower to make your lab equipment . . . once upon a time you did. This does not denigrate earlier discovers (or earlier coding) as, until it's done/discovered/developed the little pieces that make the world go round weren't there.
Consider toggling a PDP8 for the boot-strap, maybe a paper tape to follow. The coding you did was comparatively simple. Now, the computer boots right up along with all of the traducers you could want - so you have to do things with ever more complex scenarios. But, libraries of code exist to help with that. You don't have to develop your own compiler to get started (any more, unless you really really want to).
Now the above can clearly be argued with as a grand generality - but as a synopsis, the coding one needs to do gets ever more involved. Fortunately, the experience that got you there helps smooth the journey.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
"Consider toggling a PDP8 for the boot-strap, maybe a paper tape to follow."
Well that sure brought back some fond memories. Immediately triggered thoughts of 12 bit words, octal and how much you could actually accomplish in 4K.
|
|
|
|
|
I remember figuring out how to make a TAPE Bootable on a PDP-11...
Copying over the bootstrap loader, and a sil... (using PIP, of course).
The good old days...
|
|
|
|
|
The frameworks we use and the way we interact with them are getting more complex, and the jobs we are doing are - generally - getting bigger. So in theory, there is "more to know".
But ... speaking for myself, I'm getting things done faster, because those very complex frameworks do most of the donkey work for you. I can write as single line of code:
Dictionary<string, List<string>> groups = rawFiles.GroupBy(r => GetDateFromPath(r)).ToDictionary(g => g.Key, g => g.ToList()); to group files together by week or day, instead of having to write a big long method - and then test it, test it, test it - and be reasonably certain that it's going to work first time.
Yes, I have to write a "helper method", but that's one line of code as well:
private string GetDateFromPath(string path)
{
return Path.GetFileNameWithoutExtension(path).Substring(2, 8);
}So yes, it's getting more complicated, yes the learning curve has gone way off into the distance, but ... the code I'm producing is more readable, more reliable, and quicker to produce as a direct result.
So I have to say that the increase in difficulty and complexity is making my job easier and less complex ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
To extend what Griff said a little, I feel as if it's more systematic complexity. We build (or have built for us) a lot of building blocks which, in the very old days, would have to be created by hand.
Now, we can take those fundamentals and build even more complex systems out of them.
But, that introduces (despite our best efforts) dependencies which can be very complex and difficult to understand.
So, we're able to produce much more complicated things which are, by their nature, are harder to work with.
|
|
|
|
|
due to lazy "developers", hasty "consultants" and idiot PHBs.
Either the devs just don't want to "reinvent the wheel" and end up using a jigsaw of components where 20 lines of code would have met the results easier, faster and more reliably or they build everything from scratch using coding thechniques that were dead 15 years ago.
I stay as far away from Web development as I can, otherwise my opinion would be much much more bitter. Madness lies in there.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
True in every single word.
Quote: I stay as far away from Web development as I can, otherwise my opinion would be much much more bitter. Madness lies in there.
*High five*
If web development is hell, then entity framework is the devil. Both fit together for pure chaos and please, please please they may stay lightyears away from me!
|
|
|
|
|
I'm not sure that makes sense, but taking it to an extreme:
<h1>Hello World!</h1> Software written!
Now host that page, register a domain, get a cert so it's https, add source control for when the code changes:
<h1>Goodbye cruel world!</h1> automate your deployment tools, add a load balancer for when your site goes viral, add an email server so that people can register for world ending notifications...
And it goes on an on.
The irony here is that "Hello World" doesn't even qualify as "software" IMHO!
|
|
|
|
|
Couldn't agree more. I rarely ever thought about deployment. Now it is an all consuming part of my job and I utterly loathe it
|
|
|
|
|
Writing a little website and hosting it in Azure was never easier.
Even releasing it using Azure DevOps pipelines is just a few button clicks away.
Deep knowledge about anything isn't even necessary, just press a few buttons.
Although, to get any serious work done you have to know about a lot.
Azure alone has some 100's of services, then there's .NET Core, JavaScript, HTML, CSS, frameworks and preprocessors because they all suck, package managers, CI/CD, DevOps, etc.
And then there are microservices.
Each service is pretty easy to write and maintain, not harder than when I started, but it has to work nice with all other services.
Really, the hardest part of my job, currently, is managing all the services and technologies.
And it's not particularly hard, but quite complicated!
|
|
|
|
|
|
1985....10 Print "Hello World"
yep you're right
|
|
|
|
|
Both the libraries and the target environments are getting more complex, and have more interactions.
On one hand, the libraries are getting so extensive that it is almost impossible to cover the entire language library. OTOH, people appear to be forgetting some of the basics - the virtual machine (for Java, .NET, etc.) runs on real hardware, and judicious choices can seriously affect the running speed, resource usage, etc.
This is true even for many languages that are closer to the "metal" (C, C++, etc.). Many programmers use the extensive algorithms and data structures built in to the C++ library without understanding their strengths and weaknesses. What's worse - some of them will reinvent the wheel, spending time writing code for algorithms that already exist in the library.
If I were "programming czar", I would forbid development of new general-purpose frameworks for a period of at least a year. That would give programmers the opportunity to learn what is actually provided by their current framework, rather than running after the latest "new shiny".
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
.. on what you're trying to achieve.
|
|
|
|
|
For my personal taste there are way too many "toolkits" and "frameworks" and "packages" around.
These days, everyone seems to be only assembling a large number of ready-to-use frameworks together than actually doing a creative coding process. I stopped playing Lego at the age of 10 ...
Many of those frameworks work only really good in theory, and when it comes to a high-pressure productive scenario with really high load, they all fail.
I am neither a friend of those "super-no-sql-database-frameworks" (room, entity framework, etc -- that's all running in a direction I can not live with - I'd never use one of them voluntary - I am more for controlled work at the base - using stored procedures, using real sql that *I* have under control, ... no need for that fancy "i-dont-care-about-the-database" attitude).
I am forced at work to use entity framework, but it's hard to find the words for how much I hate it. This is absolutely the wrong direction we are heading.
At the same time, where some things seem to become easier, they get more complicated and complex and the developers are giving away control to some black boxes where they have no clue about how they work.
This can't be the right path.
Just my 2 cent.
Cheers
|
|
|
|
|
In my experience software development has definitely got more complicated. There are far more pieces to the software that I build nowe as compared to when I started twenty years ago. From DevOps, cloud services, service buses, document and blog storage etc there is much more to contend with. I wouldn't say it was any harder though. I still require the same level of knowledge, I just need to juggle more pieces in the air.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
