What Gartner Is Telling Your Boss

Littlewink writes, "Esther Schindler's latest analysis reveals what Gartner is telling your boss at their annual conference. Excerpts: '"The future of application development is not about programmer productivity," said [Gartner analyst] Hoyle during the keynote presentation, "but in assembling functionality from components." [Gartner analyst] Veccio stated "Why would you ever code an app from scratch again? Why would you need to?"' According to Schindler (who does not 'drink the Kool-Aid'), Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often.'"

Comments

Old ideas and old promises

[Frans Faase]

Just like AI has been promissing us real AI for many decades, the idea of producing information systems by combining building blocks still has not become a reality yet. The whole SOA hype is just one of the many "build systems from components" hypes. My experience with building information systems by combining separate applications (and that is how most informations systems are build in practice) is that these systems often crumble to pieces due to mismatching data models. I sometimes get the idea that data modeling is one of least used methods for building information systems. I wonder why.

Re:Old ideas and old promises

[kpharmer]

> I suspect it's a common scenario.

Yep - data modeling is now out of vogue, and so it is mostly done by programmers.

Unfortunately, programmers are seldom good data modelers (if only because they seldom take the time to really learn the discipline). You can take a look at some of the very good books on data modeling patterns (I recommend the one by David Hays).

But there's no substitute for experience when you get into a tight spot - knowing when to break the old rules and use something like:
    - a star or snowflake schema
    - a hierarchy or network
    - dynamic attributes
    - materialized query tables
    - triggers
    - etc
all takes experience and knowledge. One thing that I often do when in a spot like yours - is to define a good object model at least - then use that as the basis for persistence apis. These apis can be stored procedures (best case) or views (worst case). Then (assuming you have a dba that will be owning this code) the dba is free to remap that api layer to the physical tables. Change is inevitable, but at least this way you've got one role that has access to all the code that needs to change, and hopefully your api interfaces will encapsulate the code well.

Unfortunately, stored procedure use is on the decline. But as long as you take a cautious approach with them they're not a bad thing.

Re:its in the glue or its in the code

[ackthpt]

The best solutions to specific problems are going to be custom made, at least for a while.

Yeah, but sometimes you have to gird yourself for those days when the sheep come home from being fleeced at the latest management fad sheering.

I vividly remember the epic battles that took place when managers returned from TQM (Total Quality Management) training. The all had these purposeful looks of the new acolyte and a Franklin Planner under their arm. They cooked up Vision and Mission statements and tried to get everyone on the bandwagon. It was a trying time because most of the way we already did things were obviously the most efficient. Work under the gun a lot and you tend to find the shortcuts yourself. If anything we became less efficient until the whole clamour died away and most of us returned to getting it done the proper way.

I do 'middleware', and I also do 'supercomputers'

[quiberon2]

Asking "Why would you ever code an app from scratch again? Why would you need to?" is like asking "Why would you ever want to have a baby".

Sometimes it's the only way to develop what you need; sometimes it just happens by accident; and sometimes someone gives you one to look after for them.

You don't want to have a baby very often, but it's just as well that some people have them sometimes.

We're thinking about throwing Java out. It has the same problems with 'synchronisation' that C has with 'memory allocation'. You can't get it right all the time, it's too hard.

And Intel are coming up with these 80-Core chips.

A real lot of stuff will have to be rebuilt if we do. Hopefully automatically built from modelling tools. But there will have to be people, to resolve the defects, if it is to support the business.

Re:Your boss is just an object

[aussersterne]

Trouble is, the CEOs who promote this crap can jump from ship to ship-- not all of us can do that.

Seriously. Over the years I've worked in software, networks, and publishing, and I've never had the pleasure of working under any person for longer than about a year. Invariably when I've been hired, I've had the feeling that my new boss wasn't quite on top of things.

But on top of things or not, sure enough, within a couple of months of my being hired there's always an announcement that congratulations are in order because boss will be leaving us for much bigger and better things, or has been promoted to a new and more ridiculous level of abstraction within the organization. Then there's a party and some cake and silly goodbyes.

Then, the new guy comes in. He's always groomed, young-middle-age-ish, clearly an MBA or someone who's read a few too many business books and has been wearing a tie since he was four. He wrings his hands a lot and speaks in a worried-measured-reassuring tone and holds "orientation interviews" (or some variation thereon) with everyone during which he asks a lot of dumb, general, or both questions and says that he'll appreciate help in getting up to speed and he's really excited to have the opportunity to work with everyone.

Within the first two-three months, he'll fuck everything up, miss a pile of obligations or responsibilities, implement a whole slew of unworkable programs, misrepresent nearly everything we're doing in meetings with upper management, and then after a few months, just as everyone gets the feeling that he might finally be having to face the realities of the business, pull his head out of his ass, learn and scale back a little, and roll back some of the stupid changes he made, there will be an announcement... and a goodbye party...

And in will come a new guy, pick up all the old guy's stuff that wasn't quite working anyway, and soon there will be the meetings again... and the initiatives and changes again...

Wash, rinse, repeat as these jackasses earn six figures and get promoted up, up, and away in their beautiful balloons while the people at the bottom do the real work *in spite of* their idiotic tie-speak, with nary a reward year over year.

History question

[Beryllium Sphere(tm)]

Over their lifespan, has the Gartner group been right more often than could be accounted for by chance?

What are some examples of them being right?

Crank up the organ, monkeys...

[TopShelf]

Here we go, 500 comments about how management doesn't know anything.

Not to scare you

[RingDev]

But this type of IT organization is not limited to games. I work for a very successful business equipment solution company, and it used to be almost exactly as the GP described. I say Used To because the top brass finally realized that IT was blowing money like crazy. Now they have an 80% turn over rate in 2 years on the network side of the house, 30% on the apps side, budget cut backs, staffing cutbacks, and all round low moral. I recently wrapped up a pair of BSs in IT and Technology Management. I've been working hard to implement project management procedures, and get some kind of order in the shop, but my supervisor is content in code & fix mode, and my manager is 3 years from retirement and has no idea what IT Alignment is. And this has hardly been limited to this company, I have worked for enough organizations to know that this is the more common approach to IT, not the exception. And that is why I'm trying to move from Code Monkey (tm) and Project Management.

-Rick

What's old is new

[DaveAtFraud]

(2) Message-passing. Academically it's embodied in the "pi calculus". In web terms it's embodied in the W3C "choreography" working draft. In practical terms it's embodied in Microsoft's Biztalk and in Ericcson's Erlang language and in Microsoft's new Robotics SDK. It's also a little reminiscent of "tuple-space" operating systems. The idea is that threads communicate by sending messages to each other. It's still possible to deadlock (e.g. if one thread waits for a message that will never come) but these errors seem more rare in practice. Also it's easier to analyse for this kind of problem at compile-time than it is with synchronization.

This was the standard design paradigm where I worked in the 1980s (TRW Defense Systems Group). About the only difference is we were doing it with VAX VMS or UNIX processes communicating via IPC (VMS had it, it just took a little more work to implement). Hint #1: the trick to avoinding the deadlock you described is to not allow state coupling between threads. Hint #2: although rare, the deadlocks do occur and Murphy will make sure that they occur at the least opportune time.

Cheers,
Dave

Re:Gartner tells my boss whatever anyone pays em 2

[Doctor Memory]

Presently, I am consulting at a place that doesn't really HAVE a process

Is this a "Web 2.0" shop? Because it sounds a lot like the places I heard about trying to crank out web apps back in the late 90s.

I've worked with processes and without, and the best is...just having good competent developers and a manager who can both crack the whip to get things done and shield his team from the political BS. It's only happened a couple of times, but it was nice while it lasted.

Interestingly, my last gig was with a "CMM level 5" organization, who turned out some of the worst code I've ever seen. They gathered requirements (which the client couldn't completely verify, due to language issues), then created their use cases, then their sequence diagrams, and then they proceeded to cut and paste existing code into EJBs. The result is totally unmaintainable (as they found out when they had to add a new requirement to an existing module), and largely non-performant. They were able to address the performance by splitting the app between two machines (one of the few nice things about EJBs), and since they're contractors, they won't have to address maintainability. So much for CMM level 5.

The place where I work now is a total cowboy shop. No source code management, no process, no procedures, total anarchy. And it works pretty well. Pretty soon we'll have a source code management system in place, because *I* don't feel comfortable without one, and because when I told that to my boss he said "Go ahead and set one up". He also told me I could write a task-tracking database system in Ruby, which I'm looking forward to as I've never used Ruby before. But this all works because we all have pretty basic tasks (data comm and data conversion) with pretty well-defined deadlines and everybody's pretty competent. We don't miss deadlines and we don't screw around with new technology on customer-related tasks (unless it's unavoidable, like when we all sat down and learned SOA because we had to interface with a new system and that's the interface the vendor supported). I think it helps that the tasks are pretty discrete and tend to have short deadlines (two weeks to a month is typical).

As always, having a good team is all the really matters. And that tends to be tough enough to assemble even over here, forget about it if half your developers are in another country and don't speak your language very well. I think it works with open source because OSS tends to attract people who are good at what they do and can deal with language and time zone issues, but I doubt you'll ever be able to assemble a decent team from a couple of senior developers and a lowest-bidder team from the outsourcer of the month.

Re:The problem with the component approach

[plehmuffin]

It takes 20% of the time to do the easy 80% of the work. Then 80% of the time to do the remaining hard 20%. Components give you the easy 80%. Which you could already do pretty quickly anyway, so you're really not gaining much.

Actually, you're gaining 20%. That ain't bad.

Now, with your other points factored in you might not break even, but if they can be mitigated then something which can give a 20% improvement is certainly worth considering.