Is there a future for applicaion development?

That is most certainly not true.
x2

native apps should be dead long time ago already. there is nothing you can not do via HTML5 on mobile device (at least one which is not older than 12-18 months).

Performance on mobile browsers are bad. Native apps have huge performance and user experience benefits.

If it were that simple then most of the large companies wouldn't be wasting their time hiring native developers.

Forgot to mention - there are hardly any good JEE developers around. Most are nowadays "solution architects" (= purchase some expensive middleware and spend years making it work). The remaining few are either "only developing front-end" or "only developing back-end". I have never understood this, but then again those EJB developers have absolutely no clue in developing a good front-end and are better off working with JMS and JDBC. Same can be said about front-end devs who are incapable of developing a responsive front-end design.

That statement makes you sound like one those guys that likes to work solo and write everything from scratch.

If you actually study a modern computer science degree or even read any of the books written by mayor software development gurus the message is clear. Rewriting or developing in house should be avoided unless it is justified by:
A) Cost
B) Requirements (eg. if you start changing the framework it probably isn't the right framework)
C) Licensing issues

Rewriting code that already exists means:
Large upfront development costs
Lower time to market
Maintenance costs
Untested code

A good solutions architect in Java land would be making use of most of the open source libraries like Spring, GWT, various Apache libraries, etc.

The code is well tested, there is plenty of reference material, developers are easy to up-skill.

So many benefits, way too many to list...
 
That statement makes you sound like one those guys that likes to work solo and write everything from scratch.

Nothing wrong with using open-source and writing re-usable code. I am talking about the kind of "solution-/enterprise architects" which over-engineer everything and lose sight of how this will affect performance, maintenance, licensing, scalability. A bunch of Accenture guys will rock up and will sell whatever the hot acronym of the month is (everyone doing EJB/Entity Beans, then SOA/ESB/Workflow etc). Unless you work across the whole SDLC and have a complete understanding about business-, application- and infrastructure architecture and have never been exposed to SLAs, budgets, supports and licensing across an entire organisation, then you are not a solution-/enterprise architect (you are merely a guy who reads something on theserverside or listens to some sales pitch and installs a "best-of-breed"-product - which will agonize everyone else with common sense).

What you are describing is at most an Application Architect - big difference to a Solution-/Enterprise Architect. In my personal experience all "Application Architects" I have met were merely team-leaders or managers of dev-teams (in most cases too lazy/not very clever to write a decent line of code without Googling it first)

I have pretty much covered most of the vertical industries - financial, automative, transportation, telecoms, retail and still stand by my previous statement. Yes, there are rare exceptions in people, but the majority is not even average.

HTML5 depends on your user base - if you are developing for a bank, retail-, insurance- or cell-phone company you will still have a large IE7/8 userbase, have to work in silos and face politics every day - HTML5 is not for you.

And before you come to conclusions - in the last 5 years I have interviewed/come across over 800 CVs/candidates (80% of those with >3 years work experience and salary range of 450-650K p.a.) in the JEE environment and the majority of them could not even look at Java code and identify an Interface- vs an AbstractClass (or write a code-snipped getting a DataSource and execute a PreparedStatement).
 
And before you come to conclusions - in the last 5 years I have interviewed/come across over 800 CVs/candidates (80% of those with >3 years work experience and salary range of 450-650K p.a.) in the JEE environment and the majority of them could not even look at Java code and identify an Interface- vs an AbstractClass (or write a code-snipped getting a DataSource and execute a PreparedStatement).

Not sure that is really what an Architect should be doing...

eg. I use Springs JDBC template and parametrized row mapper for low level JDBC so I couldn't do a Java Prepared statement off hand either.

My point: Everyone has their own set of technologies. Testing knowledge that specific for an SA seems a bit strange since Java is so vast that it is easy for someone to not have used Prepared Statements.

Even if they had, when was the last time they used it? I personally use JPA 95% of the time and JDBCTemplate for performance sensitive queries (which are read only 99% of the time).
 
+1 to the gnome.

using "pure"/lowlevel JDBC is usually foolish, not hip and cool and techsavy. it wastes time, wastes money, and is extremely "error" prone.
this of course goes for everything that you "think" you can make better, but will actually turn out to be a pile of crap.

I have said it before, but if you are writing any code that is not business related, you are wasting your client/companies time and money
 
This thread provides epic lolz (of pity) when you read the comments made by n00bs totally oblivious to enterprise development.

Because of hardware integration requirements and security issues, "web" development is still has a long way to go before killing off (desktop/native) application development. In fact, enterprises do not like to have their systems built on cutting edge technologies and don't like "change" that much.
 
This thread provides epic lolz (of pity) when you read the comments made by n00bs totally oblivious to enterprise development.

Because of hardware integration requirements and security issues, "web" development is still has a long way to go before killing off (desktop/native) application development. In fact, enterprises do not like to have their systems built on cutting edge technologies and don't like "change" that much.
This is why I enjoy "enterprise" development so much. The reluctance for change means having to integrate with a miriad of legacy systems. I for one find this a lot more interesting than building controllers and views all day.
 
This is why I enjoy "enterprise" development so much. The reluctance for change means having to integrate with a miriad of legacy systems. I for one find this a lot more interesting than building controllers and views all day.

You mean doing some "real" development! ^5 :twisted:

/ducks for flying iPhones coming from mobile devs :p



Hehe, to each their own. But I agree with you, I prefer the chaotic world of integration and large system development. BUT, I may need to make a move one day when I want to start enjoying my social life.
 
Top
Sign up to the MyBroadband newsletter
X