If you live or spend time in Silicon Valley, it's easy to forget that enterprise software exists, or that it still drives $245 billion in annual revenue, according to Gartner. Google, Facebook, and a rising generation of consumer-facing startups get the media buzz, to the point that young developers have neither an interest in …
With all due respect to Box.net
Box net can't yet be compared to SharePoint.
Huddle, can be, but Box.net has a way to go.
Written with all due respect to SharePoint (which is, none whatsoever)
Sad to agree
This is all too true, I fear. Worse, they seem to have no sense of how anything works. I'd hate to see them try to repair a leaky toilet or move a sleeper sofa. I think, having grown up in a more mechanical time, us older f@rts have some of this basic understanding.
Okay, I'm going to stop this grumpy old man mode and listen to some modern, hip music like Robert Johnson.
You mean a futon?
Don't you just take the mattress out of the sofa?
Or in what I assume must be what you'll hear anyway:
Can't we just google it?
/ceases eye roll
I've got to get back to programming in lisp and obsf. C
As for java? Who the programs happily in that mess. I'll take python or even C++ before I'll learn that. Well, or the NSA starts listing java cipher implementations in its class A books.
Shh. What are you doing?
We don't need no javascipt kiddies in the Enterprise Software world. We have enough problems with the plethora of PHB's to deal with as it is.
We had a 'Java' kiddie join us last year. Thought he knew everything abot Enterprise Software. It was fun watching him try to connect a Siebel system to a SAP ECC6 Server without using Webservices. He didn't last very long.
Finally, that monstrosity called Sharepoint is not enterpise software despite what Microsoft might tell you in the sales process. We call it that black hole where things go in never to be seen again.
Tux because even he knows that JBOSS in not Enterprise Ready yet.(lack of decent management tools)
Sharepoint - a running joke
Around here there is a running joke answer to someone asking you where the document/whatever you created is: on Sharepoint. Much hilarity, because the metadata is rubbish, and the search slow and inflexible.
Mind you, it was worse when there was no search index available.
Yeah, yeah, it can do everything under the sun and its just the crap way we've implemented it, but still....
The crap way you implemented it
Around here there is a running joke to answer someone asking you what time of place you live in is: in a house. Much hilarity, because the roof leaks, the walls fall down, and the floor is cold as there's no carpet and I like to walk around barefoot.
Mind you, that was before I knew what carpet was.
Yeah yeah, it's my own fault for building a house and not for HIRING SOMEONE WHO KNOWS WHAT THEY ARE DOING, but still...
I work for medium sized university with the IT dept basically split into two sides, Business and Academic. The business side tends to skew to the > 40 side of the age spectrum and deals almost exclusively with IBM, Oracle, and Microsoft. If its not prepackaged solution more than likely its not being considered. There are a few Java developers, but lots of legacy mainframe code still exists. Most of the identity management is currently on IBM mainframes but being moved slowly to a packaged identity management system. There are few java programs intermixed with lots of Cobal programmers.
I work for the academic side, which skews much younger. Most of our systems are Linux with a sprinkling of Solaris, but with the rest of the stack is postgres, mysql and php. Most of our software is written in house and instead of writing to a peoplesoft/oracle stack its coded for ldap/mysql using perl and php.
We essentially accomplish very similar tasks. The only difference is that that Business side costs a ton of money and requires much beefier machines to handle the Java stack vs the Academic side has smaller machines (though some horizontally scaled) on free and open stack.
Of note, the Business side budget is far larger than the Academic side.
ripratm - you say true.
what you said pretty much sums up a lot of academic places...and quite a few businesses.
the 'young' side will chose agile, cheaper solutions to fix their problems. they arent
stuck in the old mind set up slashing tonnes of cash for 'enterprise' solution which is inflexible, ties you into that companies way of doing things and costs for a 'support licence' to provide bug reports!
I hope that the 'young' way blows away the crusty IT dinosaurs of the past - having seen the
resources that Oracle needs to do basic tasks and the horrible mess that overpaid 'DBA's make
of their databases I can only see the 'just give a working solution - be that web-based with PHP
or Perl, I dont care' winning.
more expensive staff to just make the already expensive "enterprise software" work than people who can create the equivalent "in house" software from open source pieces.
BTW I am certainly on "those" side of the age spectrum, but I totally concur with your sentiments.
People are fleeing enterprise software for a reason. It wastes money and spoils happiness for those involved.
"having seen the resources that Oracle needs to do basic tasks and the horrible mess that overpaid 'DBA's make of their databases"
I take it that was a joke? Have you ever spoken and dealt with real DBA's, no not Mickey Mouse prats who think just 'cos they can install Oracle and run a select statement that makes them a DBA?
Come back when you grow up and you have spoken to a real DBA, the sort who think nothing of reorganising a 15 petabyte DB in their sleep, while tuning five 100 line SQL statements on the side.
There isn't a young way or old way. There's a risk way and a less risk way. Business systems pay for proven systems with premium support. that's the difference.
No one cares if academic systems are written by kids as no money is lost, monkeys and peanuts springs to mind. Business do care, because experience is valued, time is money, mistakes are money and getting it wrong may well be the end of your business.
Its all about stakes, how much to lose? So go with the devil you know.
Good point, but not the whole story
I used to work for a big ERP vendor and consult on it nowadays.
One thing people are missing is that big enterprise software, besides being written in boring languages, on boring systems, is full of boring, critical, business rules and legislative requirements.
Cases in point:
- VAT rules are complex and better be applied correctly. EU-to-EU being a particularly noxious mess.
- EFT (Electronic Funds Transfers) file formats are complex and have country and bank specific gotchas.
- Payroll. Lots of legislation in each country. And we all love to get our paycheck, don't we?
Arriving at the somewhat stable final programs represents years of functional experts working in those domains, often across countries. As well as years of customers finding bugs and getting them fixed. Yes, even if the code itself sometimes looks like Shakespeare's 700 monkeys had too much to drink before starting. Read up Joel's warning about not throwing out old code too hastily.
So, comparing a bunch of social network, web 2.0 stuff, even if written by extremely clever coders, to something that a big multinational company can expect to run on, is a red herring.
True... but not as it should be
Open source will dominate those areas eventually. The laws ought to change too.
It's actually the regulatory/bureaucratic bullshit that drives me away from enterprise work, not the "boring" image.
<Open source will dominate those areas eventually. The laws ought to change too.>
Yea, right. laws are made by politicians and they have no concept of reality or good software. Politicians are controlled by the people who make the biggest donations, not by what is good and right!
Re: laws change
That's kinda the point - large organisations don't choose to spend more money on enterprise software because it's better! They choose it because it's the better risk - the supplier is much less likely to disappear over night.
If you invest in a piece of enterprise software you want to know that it will still be running in 15 years time. At least. And that you will get support for it. Enterprise software isn't about better, it's purely about knowing what you're getting.
There's nothing wrong with picking "consumer" over "enterprise" (or vice versa) as long as you fully understand the pros and cons of both approaches, and are willing to take the relevant risk or take a hit on operating costs to avoid it. Horses for courses.
Open Source is not the solution to every problem
... unless you're a zealot or an idiot, I suppose.
Much enterprise software was developed in-house and incorporates a tremendous number of business rules that are only applicable to that organization. There's no benefit to open-sourcing it, and certainly not to creating new open-source software to replace it.
Often there's no record of what those business rules are, except as embodied in the software. Sometimes the source has been lost, so only the functioning of the software (or reverse-engineering it from object code) documents them. Who's going to create the OSS equivalent from that?
Other enterprise software is not only complex and bound by a twisty maze of regulation, as noted above, but has to be updated frequently because those regulations change. That greatly increases the risks of OSS and strains its economic incentives. That's why open-source personal tax software (eg http://opentaxsolver.sourceforge.net/) took so long to appear and lags so far behind even cheap closed-source alternatives like TurboTax (in terms of forms supported, etc): keeping that stuff up-to-date, and handling a decent portion of the most commonly required forms, is a huge amount of labor. And bugs in such software can have very high costs, so customers want some protection, which is difficult to get when it's produced by volunteers.
But that's fine. People working in enterprise software don't want the "I can't be bothered by regulations" crowd any more than we want the "I only work in scripting languages" crowd crapping all over our mission-critical systems. We're not losing the best programmers of a generation; we're losing the laziest.
Typical enterprise job ads
Wanted - new graduate with experience in $A$ package that only runs on Mega$$$ server that you could never have used unless you already worked for us.
Not interested in people with years of experience (too expensive) or people who only have experience of Windows or Linux (not enterprisey enough)
Oh yes, I can see it now.
In ten, twenty years time. Enterprise software in jphpdotnet.
Now if I were to speculate as to why enterprise software sucks --because nobody's hiring me to architect it, natch-- because it's written from a "must tick the spec boxes" mindset. "The User" is simply too far away from The Codegrinder, and the dielectricum is made out of some of the densest materials known to man, like pointy hair.
The result is that nobody thinks about usability. As an example, the open source java (see? enterprise factor right there) ticketing thing jira does exactly what every other ticketing thing does to email, poop on it and treat it like a write-only bitbucket. The default templates appear to've been done by someone on not enough sleep and entirely too much caffeine and the resulting emails aren't in fact normal human-readable.
On a job long ago it ticked me off no end so I finally sat down and hacked them into something resembling shape. Took me maybe an hour to come up with something that already got me a lot of kudos from the rest of the company.
Thing is, it wasn't my job to do it. I could because I had access. Oftentimes people won't have such access but even so in the foss world you'd bitch, you'd get the templates to play with, and please submit patches. Apparently --and nevermind the myriad reasons, I'm talking end result here-- apathy is king in the enterprise.
If you'd like to fix it, then even a "foss mindset" won't really help because much of the problems are in the structure of the company and things like your job description and needing to perform and being stuck with a narrow remit, and once you're past that you'll run into office politics for most companies are dysfunctional to an awful degree, moreso the bigger they are. Should you proceed past that you run into paradigm problems with the software, as in to me a software tool isn't useful unless I can script it (yes, command line junkie here), but what you see on the enterprise desktop is "industry standard" clickibunti stuff that requires a lot of hoop-jumping to be automatable in a horribly brittle fashion. See the hurdles? We're not close to the code yet.
it is about choice
Back in the 80's it seemed we had a choice between enterprise of small business. I chose to small business. Later I saw what was available in enterprise. While we might idealize it, realistic people see the fallout of the of CRM and the expense of MS licenses and the never ending customization of enterprise software as a money pit that has brought more than one firm over the edge of receivership.
Which is to say that there has always been layers of software. What is being written now, connecting widgets to databases, is just another step in bring the tools to the masses. Small firms could never afford solutions from IBM or santa cruz operations. These were 5 times as expensive as the acceptable solutions provided by MS at the time. It is about the cheapness of clock cycles in 1990 and memory in 2000 and bandwidth in 2010.
While scalability and consistency and other basics still exist and are important to people who think in terms of enterprise, that one must pay someone like BEA or SAP to customize their solution is no more certain than requiring that men in blue suits provide your hardware.
As a 20-25 year old software developer, I agree with this totally.
And now for a rant about other 20-25 year old programmers...
My first experience of writing software was on my dads old ZX Spectrum (the posh +2A version with the integrated tape drive!) when I was 5 or 6, and it has stood me in good stead giving me a solid understanding of how to write efficient, low-footprint software.
We recently had to recruit a new software developer to work in my department, and the quality of the candidates was SHOCKING. Asking the candidates to explain the point of the .NET CLR, not one candidate could give me a sensible answer.
How can these people be expected to write decent software in a high-level language like C# when they don't even know the basics.
I'm sure they could all make a very flashy and pretty website with jQuery though...
Problem is your a nerd, and you're looking for other nerds
(Hey, I'm a nerd too)
It's just that most "young people" that went into Uni to do IT didn't do it because they're all that into computers. They just "needed to pick" a career, and somehow ended up in the IT one.
What you seem to be wanting are other nerds (ie people into this stuff just for the sake of it). When you find one, with a good work ethic (can be difficult if young), hire them. :)
Can I try?
The .NET CLR is a sort of interpreter for all the languages MS allows correct? So the point must be to allow anyone from 'any' background to develop Windows programs?
I'm just outside the 20-25 year old range and yes I make flash pretty websites with jQuery, done so for the past 6 years and have replaced 'enterprise' software with web based alternatives. And when I say web based alternative I don't mean just in one language using one 'stack' but in all the languages and stacks you have to learn in order to create a good web based alternative.
I also interviewed candidates for jobs as I became the head developer in one year after starting my real job after leaving Uni and unfortunately the level of candidates for web development is worst. We got tons of enterprise programmers believing they're master of all domains wanting to make good flash pretty websites with jQuery but they fail on so many levels that I'm not even going to bother to explain in this post.
I did also work for a Financial Institution and had to deal with their enterprise database and admin system along with a retired enterprise programmer whom showed me the ropes while I was studying in Uni to pay for my living expenses though. Mind you I may have gotten the .NET question wrong because I was dealing with classic VB and never had any real experience or interest in .NET.
This leads me nicely to the point someone made above. To someone like me, if I want to jump onto enterprise programming, I can do so and get things done properly within 3-6 months even if I don't have any prior experience in the packages or languages involved. The problem is yes most recruiters would only hire people whom at least know 'in theory' how certain package/system works without first trying to assess how well they can pick up new ideologies and languages.
It's a vicious cycle.
and the final point being in this post, programmers trying to get a job at a multi-million dollar startup as a web developer just doesn't work. So I guess it goes both ways. I'm sure programmers can make bulky, boring, expensive enterprise systems, but when it comes to a properly working web app that serves a magnitude more users than the enterprise version. *cough*.
Good day :). Oh nice patronising title for an article btw.
Re: Can I try?
"The .NET CLR is a sort of interpreter for all the languages MS allows correct?"
Not for any reasonable definition of "allows". Windows itself (like most of MS's cash cow product lines) is written in C++. MS have given up trying to push "managed" alternatives to everything in sight, as though the CLR was an operating system in its own right. At least on the desktop, neither Managed C++ nor Silverlight could be described as enjoying any support beyond "still maintained".
No, the "point" of the CLR is running VB6 programs.
I just started learning .NET to expand my horizons a bit, and the first topic in the first chapter of my first book was about the CLS and CLR.
Good luck with that
"This leads me nicely to the point someone made above. To someone like me, if I want to jump onto enterprise programming, I can do so and get things done properly within 3-6 months even"
That's for various level of "properly". In other words: No. But you *may* be starting off on the good road.
I don't know of any other engineering sector in which young people assume that they can do something "properly" in 6 months. In 6 months you will just have survived the first horrendous pile up.
Now go fetch me some coffee.
Re:Can I try?
Sorry for being off topic.
>> along with a retired enterprise programmer whom showed me the ropes
In these days when people tend to use "who" whether or not it should be "who" or "whom" you would think it would be a pleasant diversion when someone uses "whom" when it should be "who".
But it just feels like someone is stamping on my bell every time I see it.
Facebook scientest: "the best minds of my generation are thinking about how to make people click ads. That sucks."
No the best minds of your generation are taking freely available tools and software, and building massive distrubuted computing systems that power some of the biggest websites in the world.
and then look back
the best minds of his generation are taking freely available tools and software, and building massive distributed computing systems that power some of the biggest websites in the world.
And the only way those marvels of technology are able to plug into the "real money" economy is by plastering ads all over the place and making people click on them.
Now, THAT sucks!
Now, THAT sucks!
The alternative to ad-funded development is - enterprise software that costs a fortune. Up to you which you prefer, but programmers need to be paid at some point...
The 'FlatFile' format question is a killer
for these 'Java script kiddies'.
They come for an interview and go away with their tails between their legs when you ask them how to handle awful flatfile format messages that you have to send over encrypted HTTP to a server on the other side of the world.
And they have never heard of Cobol Copybooks (te-he). not hip enough for University these days.
The final killer interview question is the subject of 'Compensating Transactions'. You just get blank looks.
Doing Enterprise Systems requies a very different mindset and approach from that snazzy stuff at the front end. Not losing data is right at the top of the agenda. You can't ignore errors and all sorts of auditing and compliance 'stuff' has to be done that those front end hackers couldn't even dream about in a month of Thursdays let alone Sundays.
Forgetting a few steps...
"Doing Enterprise Systems requies a very different mindset and approach from that snazzy stuff at the front end." ".... that those front end hackers couldn't even dream about in a month of Thursdays let alone Sundays."
Nor did you exactly dream of it, or come by the mindset from talks by the hearth with ole dad. You found out by a little soft education and then a lot of hard education in the school of real life, on the job.
Thing is, so many forget where they learned or how they learned or how brutally long they learned to know all this stuff. Or who paid the costs.
Let's be honest - you learned while someone paid you while you were still yet ignorant.
Now, of course, you want people dropped in your lap all well-rounded, knowledgeable, competent and ready to go to work - all the bugs worked out.
You wouldn't buy software with known bugs, right? So you want to apply the same logic to prospective wetware purchases, right? Why everybody does!
So no applicants are good enough, as it is too easy to demonstrate the bugs, missing features, slow execution speed, and that oh so horrible UI. (And unreasonable price if they are 'almost' good enough.)
Companies want something for free. They want to skip from phase 'useless' to phase 'useful' without paying for the intermediate phases.
Dreadfully sorry about the candidates' knowledge of your particulars. Have you thought about their potential for development? Education begins with "you're hired". It worked for you, right?
Well Said Sir!
I've always been particularly frustrated by adverts that read "experience in XYZ essential" when the salary is at a level suited only to someone starting out in that area.
I'm an absolute bastard on many things when we recruit, but it's important to consider whether a lack of experience can be offset with a bit of training and some on the job experience.
@Steve Davies 3
>The final killer interview question is the subject of 'Compensating Transactions'. You just get blank looks.
Yeah, well, you'd get a blank look from me too. Haven't had to deal with them, though I can guess at the general idea. Doesn't mean I, or any other savvy coder, can't learn. Depends entirely on what we've worked on in the past.
Don't be so bloody superior. You need to sort out the useless from the ones with promise, yes. But don't expect people will know your biz processes right off the bat.
As another poster put it more succinctly: someone did hire you in the beginning, neh?
What makes you think
What makes you think systems that "loses data" or have a "lack of security" is acceptable?
Patronising with old tech is the worst. At least explain the concept and see if the kid can respond with the general idea of how it works. Precisely why you get blank looks when you talk about "Compensating Transactions". They look at you sir, in shock.
And you have the wrong perception of web developers. Real web developers do both front and backend equally well. Those who can't are either front-end script kiddies or back-end guru.
re: Notas Badof
I don't mind candidates not knowing 'stuff'. It's when thay have put said 'stuff' down on their CV and plainly don't have a real understanding of the product/technology.
I also don't mind candidates saying in response to the 'Compensating Transaction' (or similar) question 'I don't know'. Sadly, these are few and far between.
There is a world of difference in the impression you make in an interview if you are honest and don't bullshit. The current trend seems to be for candidates to overload their CV's with jargon and products that they really don't know to a level that would make them competant in that topic.
I could put SAP down on my CV. After all, I've done enough interfacing to it to last a lifetime with iDocs and BAPI's. But using SAP itself? nope. don't know it well enough to even navigate around its arcane menu structure. Well, not at the moment but I'm willing to learn.
How does that stack up then?
Yeah - a "bit" or training and "some" on the job experience. That's the way to skill up your workforce all right.
People lie on their CVs because that is how people get jobs
The way IT jobs are screened by reruitment "specialists", it's no wonder people have to overload their CVs with jargon and products "they've heard of", otherwise they wouldn't have enough boxes ticked to make it to an acual interview... or even a "thanks-but-no-thanks" email.
As long as recruiters/HR people keep looking for an exact match ("oh, well, yeah, it says here you know Java 6, but do you know Java 5?"), or as long as hiring companies continue to use such morons to filter out the real talent, you will continue to keep that.
What's a developer?
Is it someone who thinks that they're better than a programmer? Or is it a derogatory term for someone who thinks that PHP is a scripting language, but that Java and .NET aren't?
Developer is better than a programmer in the sense they create systems. i.e. including the design and architecture of the system. Programmer is someone that follows orders, i.e. a code monkey.
Also, a web developer is required to at least able to do java*script*. So yes in a way you're right, they also have to know scripting languages.
Of course a developer must install, configure and test all applicable systems like Apache and a RDBMS of your choice as well as deal with DNS, domains etc... properly. So hopefully you can see how much more a "Developer" do compared to a "Programmer".
A developer is more than just a programmer.
Someone that develops software.
There's more to software development than just programming, you know. There's testing, planning, building and releasing, to name but a few other roles a developer will often take on.
Apparently I'm a software engineer, which I know some people find even more contentious.
A programmer is someone who thinks software can be finished.
A developer is someone who knows the job is never completely done.
'Finished' is a word with many meanings.
Re: What's a developer?
Anyone who thinks there is a meaningful difference between "developer" and "programmer" needs a reality check, preferably on the back of the head. Sociologists may enjoy winkling out distinctions like these, but society at large doesn't bother and so neither should we. Like hacker and cracker, there may have been a distinction once, but not any more. Deal with it.
It's your play for immortality!
Write enterprise software! It'll likely be in use long after you're dead. ;)
With some luck you will be wheeled straight from the doorstep of the retirement home to a consulting position.
I remember a Bob The Dinosaur. He could code COBOL and point to errors in stacks of RPG 80-column horrors but if you tried to ask him something, he just mumbled incoherently like a version of Alan Greenspan until you went away. He eloquently complained about the young ones though.
Even Enterprise developers forget
The problem we're having is that even enterprise developers and support people are forgetting what "enterprise software" means.
It means that you don't just test for five distinct accounts, you test for 3000 distinct accounts and that may not be enough. You then discover things like "right click on the user and choose this option" really isn't practical when you're facing repeating the gesture thousands of times.
You don't just test the entire software stack loaded on a single PC, you test the software stack distributed over several load balanced machines and durn if that clustering option doesn't work after all.
If you tested it like a real company would use it, you might have NOTICED that it barfs on multiple Active Directory domains. Or the license manager goes TU past a modest number of servers. (And by the way, it is *not* "clustering" when one server goes down and all the others fall over as a result.) Or that the application management software becomes unusable if it has to manage more than four machines.
If you can't figure out how to write or support Enterprise software, go back to Google.
It isn't ignorance
I'm a little older than the Y Combinator set at 28. I graduated university and went to a (shall remain nameless) utility company. The department was using an Excel spreadsheet to track all the work- it was a total, utter mess.
I built a small, quick .NET app (using an Access backend- it's not so gross when you strip away the frontend, you know). Productivity skyrocketed (no more entering the same data in six different places) and I was proud. Ready to move onto the next, bigger challenge. Except it turned out that all of those challenges had been taken by an outsourced development team that slowly converted every single app (including mine) into a creaking, awful SAP solution. The IT department was packed out with awful middle managers who waffled on endlessly and never made decisions. They commanded an insane budget and spent it on the stupidest things I've ever seen.
I left. I now work for a startup, and I'm not heading back into any kind of 'enterprise' world while I can avoid it.
You're behind the times.
Any 20-25 that don't know about Java now-a-days is rare. One word: Android. Unfortunately if you want to join a hip web startup, just knowing how to create web apps aren't enough anymore.
Middle-aged middle-managers have gotten over the "Web 2.0" buzzword set and are on to the new and improved edition; mobile apps.
Re: one word
Are you suggesting that "Java" and "Android" are related?
Icon: Mine's the one with the legal brief in the pocket.
- Does Apple's iOS 7 make you physically SICK? Try swallowing version 7.1
- Pics Indestructible Death Stars blow up planets with glowing KILL RAY
- Hands on Satisfy my scroll: El Reg gets claws on Windows 8.1 spring update
- Video Snowden: You can't trust SPOOKS with your DATA
- 166 days later: Space Station astronauts return to Earth