Skill Supply and Demand

  • Comments posted to this topic are about the item Skill Supply and Demand

  • In terms of building a mechanically working data store within a NOSQL store my experience is that it is actually easier. The more difficult ones are those that have structures analogous to RDBMS concepts because the familiarity tricks you into trying to treat it like an RDBMS.

    The problem I find is that the disciplines that are needed for good data husbandry are even easier to bypass.

    Data as a resource is not like other resources such as money or fuel. Using it does not consume it therefore you can use it time and time again. If you can use it time and time again then the opportunities to get return on investment in that data are very high. The caveat being that the data has to be recorded with exacting standards and correctly modelled.

    The other sticking point with the NOSQL stores is how to get data out of them and into a data warehouse. Projects such as Apache Spark (distributed compute framework) offer a potential solution and have already been incorporated into the Hortonworks Hadoop ecosystem and the Datastax Cassandra stack.

    Operational data stores based on NOSQL aren't the problem its the end-to-end that lacks maturity.

  • Hi,

    We have experienced exactly this problem in our organisation. The majority of our databases were created and maintained using Grails and Groovy scripting. It cost a fortune to hire a contractor skilled in Grails and Groovy to complete one project.

    I have ended up spending hours learning Grails and Groovy to maintain code. I do all my database work in T-SQL and am working to eliminate Grails and Groovy from our systems to prevent problems recruiting people with the right skills in the future.

    John

  • Watching the debate was interesting and difficult at the same time. There are several qualified people that could have worked on the project. There are several language features that would greatly simplify the development efforts of the project. The number of F# developers required is much smaller. The lines of code are drastically smaller.

    The project lead knows that changing the development language only places more emphasis in an area that currently is sufficiently addressed. The project lead knows that it is more important to have a code base that is approachable by a significant number of existing and new developers. The language and code base issues aren't greater than the current needs of the customer. Asking the lead to change the language acknowledges the commitment to the open source community while ignoring the commitment to Zero friction software development.

    Steve it would be awesome to have RedGate tools for Postgresql. It would be awesome to have a Postgresql Server Central site. I would be willing to pay for the former and actively participate in the later.

  • Now lets translate Ayende Rahien's argument in that article into language of 35 years ago.

    We could do the data handling part of our app in this new relational thing that's just come out from SDL, but there is a great shortage of SDL developers, far more developers are available for IDMS or even for IMS, so we should use one of those because the developers are in greater supply so there will be less recruitment hassle and probably lower salaries.

    If that had happened on a large scale we would still be using hierarchic and network databases not relational. But people embraced the new technology and the ones who did so gained enormous benefits from it.

    It's also quite amusing to read his argument () that F# performs badly. Just imagine that someone codes some common database task in SQL using nested cursors instead set-based joins and then claims that because IDMSX can do the task in a tenth of the time using it's mormal method of doing that thing he has demonstrated that relational databases are much slower than network databases. I'd take him for an idiot, as would anyone else who has a clue about database performance. Then suppose people comment that he's actually misused the wrong feature (cursors) for what he is trying to do and he merrily denies it, asserting that he knows what he needs and he's proved the relational model can't deliver it. Then closes comments after just 5 days (without responding to the last few). The only conclusion is that he's not just an idiot, he's an arrogant idiot and can't cope with criticism. And that seems an accurate parallel to Ayende's blog entry and the resulting comments and responses.

    And maybe the decision by companies that they can't pay people to learn new skills (your last paragraph, Steve) is the cause of so many people being imported from abroad to do cutting edge softwre engineering (and other enginering too) and is the root cause of a large number of PEs speding a lot of time lamenting the evil poicy of allowing qualified engineers from places like India, the Czech Republic, and South Korea to come to the USA and "steal" their jobs.

    Tom

  • Why should I use RavenDB when I have SQL Server, Postgres and other databases, SQL and NoSQL that have more developers, users and admins with more experience? Isn't this a case of the pot calling the kettle black?

    :hehe:

    I would be more likely to use F# mainly because it has been around, is documented and works well with C#, Visual Studio, Windows and Linux, then risk my data with some random hipster database flavor of the month.

  • emmchild (6/23/2015)


    Steve it would be awesome to have RedGate tools for Postgresql. It would be awesome to have a Postgresql Server Central site. I would be willing to pay for the former and actively participate in the later.

    It's been debated, and still is. Not sure there's a market that works here. Even the MySQL tools don't do well as apparently many companies expect them to be free.

    In terms of a site, I've thought about it. I don't have enough contacts or knowledge to run it completely, but I wouldn't mind pressing into some other area and seeing if I could get people to participate. The hard part is getting people to register to ask and answer questions and also read articles. The growth of the site, and value in some part, depends on having a vehicle like a newsletter that provides some benefits to the owner.

    I'll kick it around a bit more.

  • TomThomson (6/23/2015)


    And maybe the decision by companies that they can't pay people to learn new skills (your last paragraph, Steve) is the cause of so many people being imported from abroad to do cutting edge softwre engineering (and other enginering too) and is the root cause of a large number of PEs speding a lot of time lamenting the evil poicy of allowing qualified engineers from places like India, the Czech Republic, and South Korea to come to the USA and "steal" their jobs.

    Didn't say "can't". I mentioned it has to be a value decision for your company. It's not just choosing to pay anyone to learn, but is it worth it to pay the specific people you have? Sometimes it is; sometimes it isn't. I think you have to decide and commit to doing so if you choose a technology that you don't have familiarity with.

    Personally, I prefer to get people I can trust and use more than the people with skills. If I need something else, I want to trust the people, not wonder if they are good employees for me.

  • chrisn-585491 (6/23/2015)


    Why should I use RavenDB when I have SQL Server, Postgres and other databases, SQL and NoSQL that have more developers, users and admins with more experience? Isn't this a case of the pot calling the kettle black?

    :hehe:

    I would be more likely to use F# mainly because it has been around, is documented and works well with C#, Visual Studio, Windows and Linux, then risk my data with some random hipster database flavor of the month.

    This isn't about RavenDB over SQL Server. It's about choosing any technology based on the staff and skills you have, or can get. Every technology has some based of users, and may fit better or worse than others. It's a question of whether or not you think it's a better fit for your application.

  • Reminds me of an early lesson I had about business and IT a long time ago. I used to work as a roving helpdesk tech at a large Fortune 500 company and at the time we had both Lotus Smartsuite and MS Office; both hadn't been around for very long. One day, I learned we were dropping SmartSuite (the superior product in my opinion) and going with MS Office. I confronted our VP at a departmental meeting about it. "Why go with the poorer technical choice?" is basically what I said. His reply was "Yeah, you're right ....on technical grounds but most of our trading partners use MS Office" and then he listed the additional costs associated with going with SmartSuite instead of MS Office.

  • This isn't about RavenDB over SQL Server. It's about choosing any technology based on the staff and skills you have, or can get. Every technology has some based of users, and may fit better or worse than others. It's a question of whether or not you think it's a better fit for your application.

    I think it's called playing it safe and be conservative while trying to promote your product. The author wants people to use his new tech, but s***s on other new tech. (I'm amazed we ever used anything but Cobol, Fortran or Assembly with this attitude.)

    He could have wrote his database engine in Java which is "more mature" and has more developers than C#. Others in the development community have pointed out the hypocrisy. He would have been better to say, "Hey, I know C# the best, it's my project, that's what I'm using...", without causing a fuss. Now he's alienated a percentage of developers that may have want to try his project. (Any publicity is good publicity...)

    As for functional languages, I do believe they need to be looked at by well rounded developers. C# is borrowing and adding more functional features, Microsoft is still investing time and money into F#. (Eventually all languages will develop a subset of Lisp...)

  • chrisn-585491 (6/23/2015)


    This isn't about RavenDB over SQL Server. It's about choosing any technology based on the staff and skills you have, or can get. Every technology has some based of users, and may fit better or worse than others. It's a question of whether or not you think it's a better fit for your application.

    I think it's called playing it safe and be conservative while trying to promote your product. The author wants people to use his new tech, but s***s on other new tech. (I'm amazed we ever used anything but Cobol, Fortran or Assembly with this attitude.)

    He could have wrote his database engine in Java which is "more mature" and has more developers than C#. Others in the development community have pointed out the hypocrisy. He would have been better to say, "Hey, I know C# the best, it's my project, that's what I'm using...", without causing a fuss. Now he's alienated a percentage of developers that may have want to try his project. (Any publicity is good publicity...)

    As for functional languages, I do believe they need to be looked at by well rounded developers. C# is borrowing and adding more functional features, Microsoft is still investing time and money into F#. (Eventually all languages will develop a subset of Lisp...)

    I played with Lisp and Prolog in college back in the early 80's. I liked Prolog, just never used either outside of college.

  • I don't think a lack of skills on the market should be the main point driving adoption (or not), of a new technology. I also don't think technical ease of use or code superiority (or perceived technical superiority) are strong enough reason to upheave a competently operating system.

    However, I would flat get busy finding a replacement if the old system could no longer meet business requirements or was edging into manufacturers obsolescence. In those two cases, the only really valid reasons for scrapping a working system; the organization has an opportunity to adopt better, faster, new/emerging technologies. And with those two situations, the number of developers that are trained in the new technology doesn't really matter. Employees will get trained or be acquired in order to support the new system.

  • In those two cases, the only really valid reasons for scrapping a working system; the organization has an opportunity to adopt better, faster, new/emerging technologies.

    True.

    The question is: Are the newer programming languages offering enough to make an investment in learning them?

    Many of the folks in the F#, Haskell, Ocaml, Clojure and other functional/static type camps think so. But as a developer, you are sometimes torn between being productive in what you know and learning new languages.

  • The trick is to pick the winners. The problem is identifying them.

    There are hundreds if not thousands of NOSQL solutions. What is it that allows one to succeed and another to fail? Sometimes it is being in the right place at the right time rather than a true technical advantage.

    One of the questions asked in an RFI/RFP process is whether the vendors have references from companies operating in the same or similar sector. For most companies IT is an operation cost centre. It isn't seen as something that drives competitive advantage. There is very little attraction in being an early technology adopter

    What is needed is a culture that supports low cost experimentation and has the processes to enable it to happen. In such a culture there is the possibility of allowing a development community room to play and demonstrate the value the business can gain from adopting the tech.

    To be Frank I have seen may technology changes that ultimately delivered little to the business other than a different look and feel that could have been delivered with existing technology in a fraction of the time and at a fraction of the cost. Had someone chosen to spend the money on training and tech debt the time spent replatforming an existing system could have been spent on broadening the products on offer.

    I am finding cases where there are competing technologies where there is no clear winner it would be just as valid to roll a dice to choose rather than go through a lengthy and expensive selection procedure. This is doubly so for some areas covered by open source products. Instead of fixing a perceived deficit a completely new product is created that has 99% of the features of its competitor plus the deficit. This just makes the selection process harder

Viewing 15 posts - 1 through 15 (of 37 total)

You must be logged in to reply to this topic. Login to reply