Reply to: Is programming getting easier

[VectraMan]

When one area of complexity is simplified, it means we can do more with software, and more is expected.

The raised level of expectation means the opportunity remains constant. Or even increases.

We can now write code at a far higher level, much more abstracted, than say in the 70s. Are there now less developers? Quite the opposite. Rock on!

Kind of what I was going to say, but less fancy. The building blocks have become the tools of the trade, and having more advanced tools just means that you can do much more.

[eek]

Re: Is programming getting easier

I think the problem is that companies no longer want the masterpiece if something edible is cheaper and fulfils the satiate hunger requirement.

As plan c is based around the the iterative system most companies use I can safely say that just about edible is the approach most companies do.

[SupremeSpod]

There's different levels of gluing expertise. Selecting the right bits and gluing them together in a way that is maintainable, robust and extendable is still a skill that many lack.

A bit like cooking - give me and Norrahe the same ingredients and I'll throw together something edible whilst she creates a masterpiece.

I think the problem is that companies no longer want the masterpiece if something edible is cheaper and fulfils the satiate hunger requirement.

The real problem is that you obviously need to spend more time in the kitchen! Now, put the kettle on, love.

[ottopilot]

When one area of complexity is simplified, it means we can do more with software, and more is expected.

The raised level of expectation means the opportunity remains constant. Or even increases.

We can now write code at a far higher level, much more abstracted, than say in the 70s. Are there now less developers? Quite the opposite. Rock on!

[suityou01]

I've actually been offered two jobs this week on the back of a tool I wrote about 8 years ago. So no thought required, I'm off to develop the next generation

[doodab]

I've actually been offered two jobs this week on the back of a tool I wrote about 8 years ago. So no thought required, I'm off to develop the next generation

[suityou01]

Aaaaaaand it's nice to have started a thread that prompted a genuine and useful debate, which comes as a personal point of pride after all the whingey ones recently

What I meant was, say for example MTT, is a test manager with many many years experience. He can get gigs, for now at least, but how does he distinguish himself from the herd? If for example Mich wrote a book, or developed a new testing methodology he would then have an edge.

I agree with Doodab that those that can do so long as they stay sane enough with all the other dross that claim to be skilled IT workers fecking things up.

But what can you do to capitalise? Obama said never waste a good crisis. So there's a market slump, Bobitis, etc etc.

Blog, develop a tool, or framework, or methodology, write a book. Whatever, but shine.

Now, how does the panel feel about that? Am I talking hogwash, or inspiring you to give it some thought?

[NorthWestPerm2Contr]

This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

Totally agree with this - you need to have attention to detail and visualise what you are doing rather than just get it to work - this is what has got me the most recognition over the years.........


I have just completed a training course in Tableau, has anybody used that? (Has a lot to do with what we are discussing here i.e. there is a lot less gluing left to do and everything just seems to come together).

[tomtomagain]

>What do the panel think? Are you happy doing the gluing, until your job is no longer there or do you become a manufacturer of the parts?

I think a better thing to consider is the "model" that companies will adopt over the next decade and how that will alter the IT jobs available and the skills required.

The first IT model was : "Do everything in house. Write our own systems. Employee Programmers"

Then came : "Do everything in house, but use contractors & consultancys because we don't want to have and don't have a career path for programmers"

The next was the "Bobification" of the development. Or "Give it to someone else".

Offshoring to low-cost countries has largely failed and certainly not delivered the expected returns for all the reasons that have been discussed adfinitum on this forum. Namely : lack of skills, cultural barriers, lack of risk taking and initiative, narrowing of costs between Western and lower-cost development centres.

But also I believe it has failed because of the "Linear" business model of the likes of Wipro, Infosys, Tata, Indenture. They need to employ as many people ( or "resources" or FTE as humans are quaintly know as in HR ) as possible. This is how they make money - by having as many chargeable people as possible, working as slowly as possible, for as long as possible.

So the obvious penny is now dropping in IT departments across the West as they finally realise that the contracts they have signed up for are delivering less and costing more. IT departments are everywhere are waking up to the fact that they are perceived as blockers rather than enablers of businesses. They are struggling to figure out how they can remain ( or even, if they should ) relevant in an IT world where people Bring Their Own Devices to work, are comfortable using Dropbox and googlemail and where the marketing department can sign up to Office365 and SalesForce.Com and have 95% of their IT requirements met.

So what will come next? Well for one it will not be a return to doing everything in house. Those days are long gone and anyway weren't perfect in the first place.

I think that the next model is going to be whole-scale adoption of "cloud services" ( i hate that term ) . We all know that "Cloud" is just a tag and doesn't describe anything new that hasn't been done for at least 15 years but by "cloud" I mean the complete contracting of a service for some particular function.

Using SAP as an example it would mean having one single organisation implement, host, support, upgrade, patch and do the project work for the system.

In other words distribute work vertically to organisations rather than horizontally as is currently the case.

So what are the skills required in this brave new world? Data management ( certainly ), Security ( definitely ), evangalism ( the promotion of certain platforms and tools ), programming ..... still required for integrating between services and also for building what the market wont provide.

[NotAllThere]

This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I did some analysis a few years back. It turns about 10% of developers fall into the category of non-hacker. I recall they were in quite different myers-briggs categories (for what they are worth) than the hackers.

[rl4engc]

Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I once worked as an embedded softie on a system for a high profile passenger aircraft, and had to peer review a package of code this guy had written to get 3 DSP's talking to each other over two channels. (Imagine a triangle ABC with two channels between each node). But if any comms channel between two DSP's went down, message still needed to be routed via the 'other' DSP. (So it had to act as piggie in the middle).

It was going through his code (all done in C, from 'first principles') I realised:

(a) Software Development is also an art; there is a certain beauty to see in code that is finished, working, maintainable and efficient. No different from a mechanical machine like a watch or a differential.
(b) I was never going to be a brilliant Softie. So I've settled on being a mediocre one.

[proggy]

Linky



What do the panel think? Are you happy doing the gluing, until your job is no longer there or do you become a manufacturer of the parts?

How would you makes this shift in your field? Is this a wake up call, in that we should all be thinking about simplistic plan bs that would help us differentiate ourselves from being a gluer?

The boy simonmac was doing his web site the other day, most commendable, but is it enough?

Thoughts?

It was always gluing bits together, the abstraction level just get raised each time there an "advance" in programming language design. It used to be functions, then modules then objects then components then services etc......

[Mich the Tester]

This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I agree but it's not enough. IMO developing applications and systems, including 'processes' that will be used by humans requires empathy. Too many organisations have automated all sorts of processes, connected all sorts of applications and then de-skilled customer service, and customers end up in a Kafkan trap, having to try and find their way through opaque procedures while not being able to talk to a person with the expertise to help them. Telecoms and government are particularly bad in this, but many other companies fail here; a developer with empathy will build an application that serves the needs of the customer or user, and reassures the user that his problems will be dealt with. A designer/architect with empathy can ensure that a system is clear to the end user, and that there aren't ways of getting trapped between two departments, or that your data is incorrect in thousands of databases and can't be corrected. IT people might do well to read Kafka's 'The Trial' or read up on Habermas's Lifeworld/Systemworld distinction. Strangely, I come across more and more testers who take an interest in literature and philosophy, particularly testers from the Context Driven Approach. There ARE developers who do this, but I think they're rare; maybe they are just too pressured to learn the latest tool instead of broadening their intellectual development.

The Dutch national ombudsman touched on these issues in an essay that's worth reading. He's talking about how government deals with people, but it could just as well appy to many large organisations.
http://www.nationaleombudsman.nl/sit...ls_artikel.pdf

[MyUserName]

It can be the case of glueing things together STL, Boost, MFC etc. However, understanding what needs to be glued where takes someone with skill.

Understanding what to do when glueing things together does not solve the problem takes even more skill!

[sasguru]

There's different levels of gluing expertise. Selecting the right bits and gluing them together in a way that is maintainable, robust and extendable is still a skill that many lack.
.

This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.