Survey: Slow development cycles the #1 concern

Discussions

News: Survey: Slow development cycles the #1 concern

  1. Compuware last week unveiled the results of its 2003 IT Professionals Survey on Application Development. The study of 200 people found that slow development cycles were the No. 1 application development challenge. Among other interesting datapoints, about 2/3rds were using Web Services in some form on their projects.

    Check out the study:
    http://www.evanspartners.com/compuware/compuwareITSURVEY.pdf.

    Related article:
    Survey Finds Java, .NET in Wide Use for Web Services.

    Threaded Messages (49)

  2. No wonder[ Go to top ]

    -- about 2/3rds were using Web Services in some form on their projects

    No wonder those that responsed have slow development cycles. It's case of people using the wrong technologies and over-architecting solutions. In other words it's a problem of people abusing their positions so as to boost their resumes or pure stupidity.
  3. I think the popular technologies should be accomplished with specific design tools for those technologies.
    Sometimes ago we had our own test how it affected on development cycle. The result is bellow:

    ------------------
    It was a large project for one of the New York Exchange. Two teams of developers started to do the same project at the same day (June 24, 2002 as
    I remember).
    First team - 5 developers. Created project based on Struts Framework. They used JBuilder for Java editing and text based editor (Home Site 4.5) for jsp editing.
    Second team - 2 developers. Created project based on Exadel Framework and
    only Exadel X-Studio as an IDE had been used.

    Both team shared the same System Requirement and built web interface based
    on the same design.

    As a result:
    First team finished job at the middle of October (one and half weeks before
    deadline, by the way). - 17 weeks from the beginning.
    Second team finished job August 8, 2002 - 8 weeks from the beginning

    Both applications have the same user interface and the same functionality

    Total:
    17 * 5 = 85 men/weeks vs. 8 * 2 = 16 men/weeks
    ---------------

    Regards,
    Sergey Smirnov
    Exadel Inc.
  4. All human beings are not equally productive.

    So the next question to ask is, say you switch the team around.

    Have the 2 guys use struts, and have the 5 guys use Exadel, would the team with Exadel still do better? Perhaps the team with 2 guys will still be more productive :) May be it's not the tool, or may be it is, but the scenario you gave can't be used to prove your point either way.
  5. I know, I know. It really hard to believe and you are not the first one who ask about human productivity. However, what about tool productivity? You write 10 lines of code and tool generates 110 additional lines for you?
    Human productivity evaluates with productivity of tools he/she uses. (It is not only about software, BTW)
    I suggest, switching 2 guys to Struts project just failed the project, because the project was very large and it was impossible physically to write so much code by just couple developers.

    We made a report for our boss about result of this experiment. Take a look, if you wish. The URL is http://www.exadel.com/analytics/ExadelvsStruts.ppt

    P.S. Actually, It was a reason we started to develop Exadel Struts Studio. The Struts is very popular technology, but it is really ineffective to use just a Java IDE to develop Struts application.

    Regards,
    Sergey Smirnov
    Struts Studio Architect
  6. I think the popular technologies should be accomplished with specific design tools for those technologies.

    > Sometimes ago we had our own test how it affected on development cycle. The result is bellow:
    > ------------------
    > ...
    > Total:
    > 17 * 5 = 85 men/weeks vs. 8 * 2 = 16 men/weeks
    > ---------------

    If you always use the best tool for the job and have the skills in house, then yes you will be faster.

    However, there's a big tradeoff. Always using this approach, you end up with trouble from:
    * finding people who know all these technologies
    * integrating several technologies
    * a greater likelihood that some of your technologies will become orphan-wear
    * the difficulty of writing tools that understand several technologies.

    Java is not the best language out there. C++ is better for systems programming. Perl is better for pattern matching. SQL is better at handling databases. Python is easier to learn. LISP and Prolog are better for AI programming. XSLT is better for XML (aka tree) parsing. Visual Basic is better for prototyping and integrating Windows apps. And so on.

    Why do we use Java and it's extension libraries for things like JDBC and pattern mating? Because it's "good enough" for most apps. You can be more productive by always using the best combination of language for all your jobs, but maintenance, support, and extention will become a nightmare.

    It's a tradeoff between the long term and the short term.
  7. <sigh> I feel that TSS is slowly becoming one big extended ad campaign for various companies.

         -Mike
  8. <sigh> I feel that TSS is slowly becoming one big extended ad campaign for various companies.

    >
    >      -Mike

    Yes, its become quite idiomatic, actually. Most of the threads at TSS follow the same pattern:

    1. Cedric will point out something in his weblog that addresses it.

    2. Cameron will suggest Coherence

    3. Someone will point out that the IDE [insert IDEA | Eclipse] will take care of this for me.

    4. Someone will either point out a JSR that addresses this burning programmer productivity issue or propose one.

    5. Rickard will perform a technical analysis of the subject on his weblog.

    6. Someone will mention JBoss and immediately send the thread into a flaming downspiral of a pissing contest.

    7. Someone will mention how well .NET addresses this issue, immediately sending the thread into a flaming downspiral of a pissing contest.

    8. Someone will mention some combination of C++,RTTI, the STL, and all their associated perils, immediately sending the thread into a flaming downspiral of a pissing contest.

    9. Jill will mention BPEL4WS.

    10. The Middleware Company will propose a case study/benchmark, which will prompt several alternate implementations.

    11. Howard will chime in about how Tapestry makes this problem easier and JSF is evil.

    12. Someone who has only ever posted here once or twice after lurking for a long time will post some wiseass comment.

    GDNR,

    Cristian
  9. Thanks for the link! (Wow, you're good.)

    [no sig required]
  10. This is possibly the funniest, most accurate thread ever posted on this site. Have you ever considered writing an app that would automatically generate posts based on your 12-step pattern ?

    The problem remains: would you use Coherence, IDEA, Eclipse, initiate a JSR, use Jboss, .NET, C++, RTTI, STL, BPEL4WS, and/or tapestry?
  11. <chuckling>

    Hello, Cris. Smalltalk or Java, you always were a keen student.

    You forgot a couple things, though.

    13. Something will pop up in the Patterns section which attempts to address the issue by carefully building an entire class hierarchy around a couple of utility methods.

    14. The testing methodology to determine the result neglected to include XP/Pair programming.

    15. All of this could be solved by test-first development, or careful use of AOP through interceptors/mixins, or both.

    16. The TSS Symposium will feature a talk/presentation/BOF on this very topic.

    17. XUL, either the concept, or the implementation, will render this approach obsolete.

    18. Neither MDA nor SOA address this key issue, and a new methodology must be created.

    19. Should the project that will implement the fix to this issue be hosted at SourceForge, or Jakarta?

    If I missed anything, please feel free to chime in.

    Best,

    Brian Neal
    Education Services
    BEA Systems, Inc.
  12. Spot on, mate. I haven't laughed that hard after reading something here in a while. I will add a couple of my own.

    20. EJB is deemed to be too complicated/slow/overkill, so a JDO/POJO/Hibernate solution is recommended. Pissing contest ensues.

    21. Struts/WebWork/OpenSymphony/Spring/Tapestry/Echo all do this a subtly different way. Page based vs. component based pissing contest ensues.

    22. [insert vendor here] has a rock-solid implementation of this using a [proprietary | not-open-source] runtime framework.

    23. The answer to this is covered in [ insert 1000+ page J2EE book ] written by [insert frequent TSS poster/consultant/author ] with [ framework supplied by book, soon to be SF project].

    24. [ Perl | PHP | Python | Ruby ] already does this with two lines of code. [ Write-only | script kiddie | OO ] pissing contest ensues.

    25. Nothing remotely resembling a solution to this problem already exists, so after a quick 5 minute Google, its determined another [ MVC | page-based | component ] framework is necessary. See #21.

    You're a funny bloke.

    Kinsley
  13. 26. 4 guys present a meta model for TSS discussions
  14. 27. Someone will mention JMS performance, and a question will come up from Mike Spille regarding disk syncs, and he and Andreas will "discuss" it.

    28. Someone will mention open source O/R, and Ward Mullins from CocoBase will speak his mind on the topic, including the potential liability pit-falls of open source. (BTW - I was happy to finally get to meet Ward at the JavaOne conference.)

    29. Somehow the conversation will move to offshore development, and debates will ensue on the value of individuals from particular regions of India.

    30. Jill Kay will point out how IBM and BEA joined Collaxa to build a standardized BPM solution for the problem.

    31. Sartoris will point out that you could have done the whole thing in C++ anyway, and ask what's so great about Java.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  15. <delurk>

    Wise Ass Comment.

    </delurk>
  16. Jboss is fantastic. it solves all problems. it is the cure for cancer and it is the first to come up with that cure. World peace, ha it solved it ages ago. world hunger piece of cake.

    tx

    Matt
  17. 32. Cary Bloom will make fun of someone's name in a response to .....
  18. Forgot the most important one...[ Go to top ]

    All you dudes forgot the main one.

    33 goto 1

    ... so I don't catch too much flak, make that PostPattern.moveTo(1);

    :)
  19. Great thread!
    .V
  20. An amusing thread. However, I think there are times when people arguing for the benefits of the solution they're involved with can be very helpful. For example, I first learnt of Hibernate from TSS forums (probably some of Gavin's posts) and I have since used it and would recommend it to clients. So long as the posts are accurate and relevant, I don't see a problem.

    And be fair on Cameron: he may have a link in his signature, but his posts are consistently insightful, and way above the average level on this or any other forum. I think he tends to promote Tangosol not by explicitly pushing it, but by demonstrating that they employ at least one really smart guy!

    Regards,
    Rod
  21. That is true, I actually familiarized myself with Hibernate (still familiarizing..) after the thread announcing the release of Hibernate 2.

    From time to time though, it seems that people tend to lean towards "TV-shopism" trying to plug their products shamelessly with no relevance to the actual discussion (I seem to recall in particular someone trying to sell their JDO-implementation in said Hibernate-thread..).
    But usually these people are of the "infrequent poster"-type, not to many of the usual suspects do that kind of thing.
    People probably learn in time what is a productive post and what is not, and I think those are the ones that count.

    Although I have to say that I was strangely happy to see Rolf post again, these forums have gone a bit dry without his comments. :)
  22. State of TheServerSide[ Go to top ]

    Talking about intelligent people (pun intended), anyone seen "tRolf" around? Has Floyd added a Rolf-filter or has he gotten a job / left Microsoft's marketing dept.? Not so long time ago Rolf was constantly among the top 5 posters...
  23. Friggin hillarious.... And 100% accurate... (I'm the occasional poster with a wise-a$$ comment)

    Rob
  24. 3. Someone will point out that the IDE [insert IDEA | Eclipse] will take care of this for me.


    Sorry to dissapoint you, but I´ll have to push Emacs here. ;)

    Well, jokes apart. I feel that some RAD and IDE tools are grossly overrated in their impact on productivity. I myself am I heavy user of NetBeans (IDEA is superior in most aspects, but for Swing interfaces NetBeans is great) and IDEA (and ANT, and JUnit and..) and would never look back at using just emacs.
    But one of the most productive developers I have ever seen used just plain emacs and ant, and I am no exagurating by saying that he was as productive as five other developers together, and the five others were by no means either stupid, lazy or unproductive. Its just that this guy was so productive it was frightening to see him in action. And his toolbox only contained emacs and ant basically..

    People are and always will be more important than any tools. One "super"-developer is worth 10 normal developers and an infinity of development tools..
  25. Sorry to dissapoint you, but I´ll have to push Emacs here. ;)


    Are you kidding? vi is way better....
  26. Using WebServices corporations can now integrate their legacy vi and emacs developers. This solution maintains the investment in tranditional stove pipe solutions, and yet leverages this distribute corporate knowledge base.

    Gartmer
  27. Yeah?[ Go to top ]

    ...
    People are and always will be more important than any tools. One "super"-developer is worth 10 normal developers and an infinity of development tools..
    ...
    Oh, yeah?
    Let me tell you about one such "super developer". He's such a fast typer that he doesn't need the autocomplete feature. When he compiles his program written in that useless emacs he's looking so carefully for that 'a' instead of 'A' that must be somewhere in his unformatted, unfolded, uncolored code that he must have developed great archery skills by now. He believes that a real developer should “feel” the code, so he doesn't do extensive copy/paste, he rewrites by hand.
    Tell me what will a super developer do when the IDE refuses to compile the pile of s..t and you need restart? Or when the code displayed by the IDE is so visually disgusting that you feel like throwing up? Beautiful looking tools make me at least stand the s..t easier. I couldn't live with those brick like windows in Eclipse for instance.
    I', not a VB programmer, but I'm tired of all this shit. I have a life, i don't like working more than 8 hours/5 days and I have no appreciation for swimming through code without the right tools and wasting time fixing otherwise minor bugs or developing easy features in hours because my tools are not first class. And all for what? So i can say nerdy say at the end of the day that I'm a “real” developer? That I could do it in notepad? I could, but I don't want to!
  28. Yeah?[ Go to top ]

    Stern: Let me tell you about one such "super developer". He's such a fast typer that he doesn't need the autocomplete feature. When he compiles his program written in that useless emacs he's looking so carefully for that 'a' instead of 'A' that must be somewhere in his unformatted, unfolded, uncolored code that he must have developed great archery skills by now. He believes that a real developer should “feel” the code, so he doesn't do extensive copy/paste, he rewrites by hand. Tell me what will a super developer do when the IDE refuses to compile the pile of s..t and you need restart? Or when the code displayed by the IDE is so visually disgusting that you feel like throwing up?

    You didn't describe a super developer. You just described a fast-typing slob. There's a big difference.

    I would explain it this way: There are relatively few developers that actually understand what they are working on. Of those that do understand, there are relatively few that take real responsibility for complete quality. However, those that do meet these criteria are invaluable, and while they may only be one out of one hundred, they are the people that become the core of successful projects.

    The problem is that developers that do not undertand what they are working on and do not take responsibility for complete quality actually end up being of negative value. In other words, every line of code they write ends up hurting the potential for the success of the project.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  29. Yeah?[ Go to top ]

    \Cameron\
    I would explain it this way: There are relatively few developers that actually understand what they are working on. Of those that do understand, there are relatively few that take real responsibility for complete quality. However, those that do meet these criteria are invaluable, and while they may only be one out of one hundred, they are the people that become the core of successful projects.
    \Cameron\

    This is only too true, and I think you've hit on the core of the issue of developer quality: understanding. I have the distinct impression that many developers I've observed are, to a large extent, groping about somewhat blind, with wildly inaccurate mental models of what a given system really does. The modus operandi of many programmers seems to be "fiddle with it until it works" - don't look for root causes, don't attempt to understand what's really happening, just keep changing code and parameters until the thing seems to do what you want.

    It sounds hokey, but really good developers take the time to understand their app requirements, their own coding environment, and the technologies they're using in depth, and the end result when they code is they "just do it". Their mental model of the environment matches reality closely enough that they are rarely surprised, and when they are they have the discipline and smarts to track down where their preconceptions broke down.

         -Mike
  30. Yeah?[ Go to top ]

    ...
    t sounds hokey, but really good developers take the time to understand their app requirements, their own coding environment, and the technologies they're using in depth, and the end result when they code is they "just do it". Their mental model of the environment matches reality closely enough that they are rarely surprised, and when they are they have the discipline and smarts to track down where their preconceptions broke down.
    ...

    I agree. I admit that my previous post was more humorous than serious. But if you believe what you say, why would you advocate typing? That's the last and lest important stage. Good tools save me from too much typing.
    I have no idea, so I'll ask: does a vi developer have a good debugger?

    Stern
  31. Yeah?[ Go to top ]

    \Pavel\
    I agree. I admit that my previous post was more humorous than serious. But if you believe what you say, why would you advocate typing? That's the last and lest important stage. Good tools save me from too much typing.
    I have no idea, so I'll ask: does a vi developer have a good debugger?
    \Pavel\

    I hardly advocate typing - in my mind, this is like a fish advocating water. The primary interface a developer has to his computer is a keyboard - the failure of various CASE tools, visual programming langauges and the like has demonstrated that pretty thoroughly. In that vein, it behooves a developer to type as damn well as he or she can, because despite any IDE that's what they're going to spend alot of their time doing.

    As for debuggers - again, it may sound hokey, but I prescibe to the "Practice of Programming's" rules there, especially for server side development. People spend a ridiculous amount of time noodling about in debuggers, casting about trying to make sense of what their code's doing. Most of the time - most, mind you - they should already know. And when they don't, logging statements in your code are superior in the long run, because as Kernigan et al state, logging statements are eternal, but debuggers are quite ephemeral beasts. The issue you solve today with a debugger may come back, and you'll have to spend all that time debugging all over again.

    I realize I sound "anti-tool", but that's not really the case. I just don't use tools as a crutch for sound grounding in the basics, I don't try to substitute technology where my brain is far superior.

         -Mike
  32. Yeah?[ Go to top ]

    <quote>
    I hardly advocate typing - in my mind, this is like a fish advocating water. The primary interface a developer has to his computer is a keyboard -
    </quote >
    Exactly! I'm sick of all this water.

    <quote>
     the failure of various CASE tools, visual programming langauges and the like has demonstrated that pretty thoroughly. In that vein, it behooves a developer to type as damn well as he or she can, because despite any IDE that's what they're going to spend alot of their time doing.
    </quote>
    The failure of some tools has nothing to do with the success of others. The old autocomplete feature and some code generators are real life useful solutions !
    (see http://www.theserverside.com/home/thread.jsp?thread_id=19296&article_count=20, where something like 70% of the code was generated! wonder how the vi/emacs developer could keep up with that)

    <quote>
    I realize I sound "anti-tool", but that's not really the case. I just don't use tools as a crutch for sound grounding in the basics, I don't try to substitute technology where my brain is far superior.
    </quote>
    You've got it just the ot
  33. Yeah?[ Go to top ]

    <quote>
    I realize I sound "anti-tool", but that's not really the case. I just don't use tools as a crutch for sound grounding in the basics, I don't try to substitute technology where my brain is far superior.
    </quote>
    Accidentally cut my text. Sorry. What I had to say is that you've got it the other way around. It's the basics where we can and where we should tools.
  34. Yeah?[ Go to top ]

    \Pavel\
    The failure of some tools has nothing to do with the success of others. The old autocomplete feature and some code generators are real life useful solutions !
    (see http://www.theserverside.com/home/thread.jsp?thread_id=19296&article_count=20, where something like 70% of the code was generated! wonder how the vi/emacs developer could keep up with that)
    \Pavel\

    On autocomplete - in my experience, Java APIs (both homegrown and standard) are large enough that autocomplete takes more time than just typing what you need. As I said, you spend alot of time squinting at pick lists.

    On what I was saying about tools - in my experience, no matter how fancy the GUI mouse-based tool, it always comes back to writing code in highly expressive languages using a keyboard. I'm not familiar with the MDA tools referenced in the article you pointed out, but personally I've yet to see the model-based tool which didn't ultimately cause more grief than the benefits it provided.

    On the larger idea of code generation - that has nothing to do with IDEs or visual modeling tools per se. You may recall some of the earliest code generators in existence known as lex and yacc - which were written in vi and emacs. I myself am a huge fan of code generation, both for pumping out boilerplate and providing persistent behaviors across a code base (as well as using more dynamic solutions which do the same sort of thing at run time).

    The bottom line is that a non-IDE developer can achieve the same productivity as someone using an IDE - and sometimes even better productivity, because non-IDErs tend to use OS-level scripting and other techniques which work cross-IDE and which scripts can grow over time. And cross-IDE is very important, at least for me - I've had to work with probably about 5 IDEs over the past 5 years on my own (corp mandated), and work with people covering upwards of 10 IDEs. When you're battered with that many changes in a short period, falling back to the basics is simply a good survival technique!

        -Mike
  35. Re: IDEs[ Go to top ]

    <<< (see http://www.theserverside.com/home/thread.jsp?thread_id=19296&article_count=20, where something like 70% of the code was generated! wonder how the vi/emacs developer could keep up with that) >>>

    Cut and Paste? Is that smart-ass enough? Seriously though, I would want to know how much of the generated code had to be "touched-up"? Or when something needed to be done that the IDE just couldn't handle. I know professional developers working on production applications with IDEs who don't know the difference between a classpath and a path, or between javac and ejbc. EJBs are the only thing I've worked with where I might prefer an IDE to good old UltraEdit. And even then I wonder if I actually save any time, between figthing with the tool, the lack of a really sweet text editor, having to switch to UE anyway to work with xml/xslt/js/txt/css/log/jsp/html/etc. files, and--due to switching jobs or rotating "corporate standards"--having to learn a new one every year or so (Together, WebGain, now JBuilder).

    Together was pretty nice, WebGain was a nightmare. For one thing it insisted on compiling and auto-deploying every time, with no way to separate the two. Tech support was pretty spotty, I guess now we know why. We also paid $5k apiece for XMLSpy a few years ago. I use it to pretty-up my XML before debugging in UltraEdit, but that's about it. (No I don't work for UltraEdit, I just like it.) The other day I was working with the HSSFSerializer from the Apache/POI guys, and I finally had a schema I wanted to validate against. I fiddled with it for an hour to try to get it to recognize and validate against the schema but finally gave up and just eyeballed the XML. Yes I could have contacted tech support, but I just didn't feel like waiting a couple of days to hear they had no idea what I was talking about or that what I wanted to do wasn't supported in this version, etc.

    I realize the similar-sounding arguments were made against compiled languages back when developers still had to routinely go in to "touch-up" byte-code. But at least with Java, I just don't think IDEs offer that much. It may be that you really need a 4GL designed around the IDE, like VB or PowerBuilder, rather than an IDE tacked onto a language. I want developers who understand the basics like the back of their hand, not as vague memories from some class. If I'm running the company and it's my money, I say screw IDEs.

    -M
  36. Re: IDEs[ Go to top ]

    <quote>
    Cut and Paste? Is that smart-ass enough? Seriously though, I would want to know how much of the generated code had to be "touched-up"? Or when something needed to be done that the IDE just couldn't handle. I know professional developers working on production applications with IDEs who don't know the difference between a classpath and a path, or between javac and ejbc
    EJBs are the only thing I've worked with where I might prefer an IDE to good old UltraEdit. And even then I wonder if I actually save any time, between figthing with the tool, the lack of a really sweet text editor, having to switch to UE anyway to work with xml/xslt/js/txt/css/log/jsp/html/etc. files, and--due to switching jobs or rotating "corporate standards"--having to learn a new one every year or so (Together, WebGain, now JBuilder).
    </quote>

    Seems to me you were never allowed to get accustomed to and use a real IDE to it's full capabilities. This is not a drawback of the sofware. I myself believe that that are only 2 usable IDE's out there (for Java and/or C#): Visual Studio and IDEA. JBuilder was too slow (at least at version 6); Eclipse threw me a runtime error at startup, no matter what the jdk version, and when a version that managed to startup appeared it was not much of progress. That open source IDE for C# is very much unusable.
    I my opinion a good IDE is an invaluable tool. That does not excuse the programmer for not knowing stuff (don't blame the IDE cause he/she couldn't tell the difference between path and classpath). I know of 'architects' (they are credited with this title and are proud of it) using joe (!) to code and not knowing the difference between checked and runtime exceptions.
    Yes, if one is smart and knows his job, he/she can be productive without many sophisticated tools. But the smartest use advanced tools too. That's being productive. Cowboy style is out.

    Stern
  37. Yeah?[ Go to top ]

    \Pavel\
     Oh, yeah?
    Let me tell you about one such "super developer". He's such a fast typer that he doesn't need the autocomplete feature. When he compiles his program written in that useless emacs he's looking so carefully for that 'a' instead of 'A' that must be somewhere in his unformatted, unfolded, uncolored code that he must have developed great archery skills by now. He believes that a real developer should ?feel? the code, so he doesn't do extensive copy/paste, he rewrites by hand.

    [...more of the same...]

    \Pavel\

    I would propose that you haven't described a "super developer". You seem to have an axe to grind about one very particular developer :-) And I'd also say that some of your statements show a rather deep misunderstanding about the development process - at least the way I see it.

    First of all - I've yet to see an IDE which actually made a noticeable improvement in development times when looked at in multi-month increments. It may sound crazy, but people using WSAD/IntelliJ/IDEA/whatever don't seem to actually create software any faster, or any more robust, then the strange character off in the corner using EMACS or even vi. Alot of this, I think, is because many people seem to believe that IDE features like auto-complete mean they don't have to understand the API they're using. I've watched a distressingly large number of developers auto-complete their way through an entire class implementation without the slightest clue what the API they were using was all about, and they spent hours debugging their auto-completed code.

    As for physical coding style - people learned over a decade ago that there is no one universal style, and the smart people stopped trying to mandate one true way. Smart organizations will actually run a pretty-printer on source code automatically before checking it into source control, so that the checked in code always has a uniform format (and diffs actually work), but individual developers program their editors/IDEs/whatever to re-format it to their own style.

    Finally, a true "super developer" tends to have a very deep knowledge in the tools they are using - language, editor/IDE, frameworks, and standards. Use of such knowledge and applying it to their problem at hand is almost automatic and intuitive, because all of the basics are already firmly implanted in their heads. The end result is they spend little time dithering, or fighting their tools, or running around in circles because they never took the time to understand their tools in detail.

    For such people, something like using an IDE is a nicety, but hardly a requirement. They may appreciate a given IDE's conveniences, and learn it sufficiently that they utilize it to the max. But you'll find that they can get the job done in vi, or emacs, or even notepad if they have to. And part of the reason is 'cuz they're not wasting their time constantly scrolling through pick lists, but instead are actually writing code and keeping it tight with their mental model of the system. Instead of fighting the world or railing against some perceived injustice, they move on and make it work.

    As for cut 'n' paste vs. rewriting by hand - you seem to be advocating a thought-free development style. That must be, ah, very interesting for you.

       -Mike
  38. LOL[ Go to top ]

    LOL.
    Best thread in ages!

    Henrik
  39. .
    .
    .
    .
    101. Somebody will use TSS to bashed or get bashed by somebody.
  40. Excellent thread[ Go to top ]

    TSS should advocate this PATTERN... BTW what do you name for it.

    -Binu
     Accenture
  41. 'Biased' posters[ Go to top ]

    On the other hand, I know that I'd probably have a lot more than my... uhm... one post if it weren’t for the fear of just that; your post being weighted on a gold platter for bias / own interests and very easily seen as a 'plug'. I'm not talking about the kind of stuff that are pure plugs, but rather any comment in a relevant area to your product(s), where you're likely to have an opinion seen as 'favouring' your stuff.

    For instance I don’t reckon we'd write an EJB (yes, entities too) server if we didn’t think it was good stuff, but I know I've bitten my tongue on numerous occasions wading through such discussions due to the above. And somehow I don’t think I'm alone.

    Regarding the signatures that's a two-sided issue as well. As soon as someone partial posts without a clear signature / definition of where he's from he runs the immediate risk of someone going "Aha! But arent you really Mr XYZ from co ABC! You sneaky...". That said I think there's many a time one has been baffled reading a post where 2/3 of the content seems to be made up of the signature and/or potential link, but I think it's a necessary evil. Personally I don’t think it really hurts too much either, except the rare cases where people cross over the line (everyone does at some point), and when they do I think it usually yields more of a negative than a positive result anyhow.

    Personally I aim to change somewhat and possibly post a bit more often though, signature and all, so I guess TSS will soon go even further down the drain. Save yourselves while you can! ;)

    [Too ashamed to insert signature]

    PS. Yes, nice thread ;). Any reflection within a community is a good sign!
  42. 'Biased' posters[ Go to top ]

    your post being weighted on a gold platter for bias / own interests and very easily seen as a 'plug'.

    A nice way to avoid these shameless sig plugs would be to have a bio in my TSS profile just like jGuru has it.
  43. A recent miniscule survey of self-selecting individuals regarding surveys of 200 self-selecting individuals have found that 99.99999% of respondents felt that such surveys made excellent toilet paper when printed out, but otherwise indicated nothing whatsoever of any value.

    A majority of such respondents also added "I like cheese".

        -Mike
  44. in other news[ Go to top ]

    Survey finds quick and short development cycle to be #1 concern for all consulting companies . ;-)
  45. in other news[ Go to top ]

    Survey finds quick and short development cycle to be #1 concern for all consulting companies . ;-)


    And non-consulting companies too.


    Lets see how they solve this "concern":

    By Hiring those who want the least.
    By Paying little and doing little to keep the most knowledgeable/able/learnable/forward thinking.
    By offshoring and hinting they are going to.
    Not putting the most knowledgeable/able/learnable/forward thinking in "charge". (no, this is not just technical)
    Not knowing/recognizing who those people are.
    Getting in the way of those who are.
    Not knowing when short is too short and long is too long.

    Companies may say they are concerned about this and other 'IT' issues but their actions say otherwise.
  46. fashion and prototyping[ Go to top ]

    The main reason for project development cycles being slow in my experience is that each new project is always accompanied by the inclusion of the latest piece of development fashion/technology. this is understandable because the emphasis is to try and put the design to the next stage to buy time in the future, but generally results in a poor implementation due to the 'rush to learn' and inexperience of the technology in question.

    the other factor is that requirements always change, and one of the causes of this is that as a business sees its ideas moving from paper to the web (or whatever platform) they realise flaws in their own model.

    one way to limit the impact of both developer inexperience and requirements changes is to develop a prototype to test both key flows thru a site, and the practicality of technology decisions. this is the way its done in most other engineering industries in order to minimize risk, but seems to me that it is nearly always overlooked in software development.

    the one project where we done a prototype resulted in a faster development cycle(an early delivery) and happier customers because they had a better idea of the final product and confidence we could deliver
  47. fashion and prototyping[ Go to top ]

    I have to agree, especially when it comes to prototyping:
    requirements will change, because the customer only knows what he wants once he sees it!
    Iterative development methods are often talked about, but rarely actually used.
    Because requirements change, I think you should work iteratively with deep rather than broad functionality being built.
    By this I mean that you should focus on a small piece of the system/software at a time to make small "prototype" deliveries as soon as you can instead of trying to do it all in one round. In that way, the customer gets to see what they want quickly and the changes required are easily implemented on request.
    I´ve seen some large projects that have tried to "do all at once" in a water-fall manner, they always ended up with the "test" phase being longer than the actual development because of all the changes that had to be made.

    I have done contracts for a couple of the big five "ivy-league" consultancys, and there is always the rush for getting requirements "approved".
    "Dont question that requirements, its approved" is a pretty common attitude.

    I am in no way putting the people or companies I have worked with down, I have met some of the most competent people I have ever met in these environments. However the pressures to get things "approved", everything from requirements to worked hours makes people go blind over what it is all about: Delivering a good end result in the shortest time possible.

    The "early approval"-process really gets in the way of that since you end up with the bickering about what it all meant in the end anyway.
    Oh, and I am not talking about allowing feature-creep here, I am talking about implementing the RIGHT features as opposed to the features the developers THINK are right.

    What I am saying has been said time and time again before me. But for some reason people dont live like they learn. The common attitude is that "it takes to much time" and is "to uncertain" about what the end result will be.
    But: as opposed to what? Developing for 5 months, then making changes to whats been done for 7 months?
    Instead of developing for 6 months, testing for 2-3 and being done with it..
  48. fashion and prototyping[ Go to top ]

    requirements will change, because the customer only knows what he wants once he sees it!


    I feel that there are 2 types of requirements:
    a) Purely business process/workflow/logic
    b) Application related

    An example of (a) would be "Process loan application" or "Process traveller's customs declaration". These would include the decomposition into detailed processes and business rules like "Examine traveller's baggage to verify his declarations" and "Calculate total duties and excise".

    IMO, you cannot accept "I don't know" as an answer for (a). If the user does not know the business rule or process, how is he carrying it out now? If he doesn't know, how can we be expected to implement it? He should have hired a business analyst instead.

    What you described is case (b). This is the one where one user says he wants all the forms to be combined into one screen, while another user says he wants it to be implemented as a wizard. This is the type of requirement which you prototype. Show your users a prototype of how you intend to implement their business process/logic in terms of application screen flow.

    (Recently,) I have read too many arguments between spiral and waterfall methodologists hinge on the term requirements. I just want to see more precise arguments/debates, rather than the stock text book 5-line descriptions.

    Does anyone have any comments, or am I just blowing hot air?
  49. Good to see some humour[ Go to top ]

    It is good to read a thread that is having some fun / humour in it. I think that things get a little bit too serious on many forums (including TSS).

    Just to add to the fun:

    30. Dion will post a news thread without thinking about it, and people will start going nuts about the post/TSS

    I can make fun of myself ;)

    Dion
  50. Well, if it's coming from Compuware I bet it's true - they know all about it. Compuware is a company that bought and marketed a tool/development environment known as Uniface. Any developer and it manager who ever had anything to do with it, can only shiver and vomit in fear when it's mentioned.