Programmers go Extreme!

Discussions

News: Programmers go Extreme!

  1. Programmers go Extreme! (21 messages)

    A glimpse at a Software Methodology that has been around for quite some time now...Check out this article on news.com that talks about Extreme Programming, a methodology originally developed by Kent Beck for Chrysler. This methodology (or I will term it as software process) has some interesting ideas about lifecycle phases and Pair Programming.

    Read Article Here

    Threaded Messages (21)

  2. Programmers go Extreme![ Go to top ]

    Nothing new under the sun, this is just common sense.
  3. Programmers go Extreme![ Go to top ]

    I agree, this is definitely nothing new. Just another bandwagon fantasy meant to overcome programmer mediocrity.

    One thing for sure. No software development process is going to make a mediocre programmer into a good programmer. Or a mediocre designer into a good designer. Or a mediocre team into a good team.

    The fact of the matter is... if you have good programmers and good designers, then you'll have a good product. No matter what methodology is used. Sure there are small things you can do to reduce code complexity and defects, but they don't have near the effect that having good programmers/developers do.

    The truth is, most programmers are mediocre at best. They are lazy. They only do what they need to do to get by. They surf all day long. They don't learn about their own craft. So people (geek pundits) try to invent these 'processes' to overcome the symptoms of this mediocrity. And believe me, 99% of all software project issues have to do with developer/designer mediocrity... don't let anyone fool you.

    The best thing anyone can do is keep learning about the art of programming. Learn the concepts. Read about it. Do some independent study. Read the different approaches about design and patterns. Keep up to date. Ask questions. Listen to the better programmers. These practices will turn a mediocre programmer into a good one over time. Enough of the theories already. Get back to the basics of good work ethics and constant learning.

    My two cents.

    -- Rick


  4. Programmers go Extreme![ Go to top ]

    "And believe me, 99% of all software project issues have to do with developer/designer mediocrity... don't let anyone fool you." -- Rick Grashel

    There are lies and there are statistics .....

    I think blamestorming the development team might leave management and senior management left out. The classic project failures that I have come across are those where a Prototype is sold by marketing as a final product and the development team have a day to turn it into something more robust. Or a CTO comes up with a plan to develop the impossible.


    If you want to improve your developers then make them read :

     "The Pragmatic Programmer" by Andrew Hunt and David Thomas
     Addison-Wesley Oct 1999
     ISBN: 020161622X

     


  5. Programmers go Extreme![ Go to top ]

    Jon,

    No lies here. First, I'm not talking about overall project performance. I'm talking about SOFTWARE. Re-read my quote which you re-quoted. SOFTWARE project issues. I'm not talking about project management issues. Although, I think the bizdev crowd just uses project managers as their scapegoats most of the time anyways.

    I'm talking about development teams who are technically not competent enough to deliver projects. The great majority of projects I've rescued have suffered these types of issues. And I'm not alone. Lots of projects are this way.

    Lack of competent resources leads to the following :

    1) slow coding time
    2) lots of defects
    3) poor design (which usually leads to #1 and #2)
    4) bad prototyping
    5) bad technical specifications

    This article was talking about issues with slow time-to-market, defects, and code complexity. I think it was a given by the tone of the article that the projects being talked about were assumed to be manageable, realizable, and capable of being delivered -- but because of no XP practices, these projects would go in the toilet. Which I personally think is BS.

    I'm echoing lots of sentiments echoed by guys like Ed Yourdon and Donald Knuth. The level of programmer competence is way down. The level of programmer dedication is way down. The level of programmer education is way down. The amount of time programmers actually spend programming is way down.

    To me, there has been enough of scapegoating the non-technical side for technical failures. Some companies have spent millions on incompetent dev teams that have no real experience -- or very limited experience. Just to watch their program fail because the software can never get finished.

    Sure, there are always going to be management issues. But development is always at the core. If you have a poor performing, under-qualified team, then that is the kind of software you are going to get -- poor and underqualified.

    -- Rick

  6. Programmers go Extreme![ Go to top ]

    Rick,

    What kind of programmer/designer are you, good or bad ?
    Or are you in the management ? :)

    Your point of view is nice, extreme (like XP) and smells from a distance as not based on research.

    You may have a hint or may reason bevause of some frustrating experience you may have had and all of us had at some point.

    1. Project Managers ARE responsible. Period. Final.

    That's why they are called project managers.
      They are responsible for all the evils you try to say:
       - having underqualified people.Not realizing that some of their people are underqualified.
       - accepting from senior management unrealistic goals ( inflated specs)
       - not focusing on providing value to the end user
       - not knowing the real staus in the life time of a project.
       - chosing bad technology, and so on , so forth.
       In everything you can think of as a cause of failures they certainly play a role.

    2. Good developers with unrealistic goals make bad projects. Developers don't have the authority to change the goals (specs, deadlines etc...)

    3. Good developers with bad technology (also they are not the ones that have the final saying) make bad projects

    4. Average developers with realistic goals and sound productive technolgies (like RAD tools) can make very good projects.

    On the reverse side, I think the project managers is the first who deserve the credits when the project is successfully comnpleted.

    XP is a good methodology to help a project manager know how his developers are doing, what's the real staus of the project and so on.
    There are also bad methodologies and they do matter.

    When you're hacking software on your own, you're right, the developer is to blame and methodology doesn't really matter.
    But then you're the project manager also.

    Cheers,
    Costin
  7. Programmers go Extreme![ Go to top ]

    Costin,

    I appreciate your comments. BTW, I am a developer. And I think I am a good one. And I think I get better and better. I am a very customer-oriented developer as well. And I've seen enough bad programmers to know that they pervade this business - and cause more problems than they solve.

    And your post, like mine, is really just opinion and rhetoric.

    For you to say that the project manager is solely responsible for the failure of a project is particularly outlandish -- simply because of their title. I assure, the project manager is as much a slave to the developers as they are to management. The consummate go-between. A very unenviable position. And the biggest scapegoat of all.

    You may have had the experience of CTOs having outrageous requests, unreasonable deadlines, underfunding projects, and starving their developers of good tools and resources -- but that isn't my experience. If I even came across that kind of a project, I'd walk away. Why would you work in an environment like that? Seems to me that its your own choice if you do -- and not a very wise one. Yet again, not-very-wise developers working for not-very-wise people. One begets the other.

    But that has not been my experience. I have been in the situation where a team has had to do things quickly, but that is the nature of the beast. That is what we do. We all can't plan around 40 hour work weeks and weekends off. This is the real world. Scapegoating the tools is a common thing, too. Blame everything else. Point the fingers elsewhere. But never look inward.

    As always, this is a debate that will always be raged over. Probably without resolve. But I still stand by my contention. Programmers don't do as much as they used to. They don't have the pride that they used to. Nor the work ethic. Nor the dedication to their own craft. Nor the quality. But... I suppose that these developers will simply blame these shortcomings on their management as well. Endless circle.

    -- Rick

  8. Programmers go Extreme![ Go to top ]

    Also, a great book to read which very accurately characterizes (especially American) programmers and talks alot about the things I've said is:

    "The Decline And Fall Of The American Programmer" by Ed Yourdon, c 1992
  9. Programmers go Extreme![ Go to top ]

    No thanks, the title of thew book is biased (maybe the book is not).
    I'm a H1B hi,hi,hi.

    As for the good developers that stay on badly managed projects: they stay to get the money.
    Lucky you if you happen to choose in what projects you work for.
    I'm also lucky currently but I've seen a lot of good people staying on bad projects. I did it myself in the past.


    Also I'd like to know why you consider my arguments rhetoric.

    Let me be more clear:
      - If the project manager has bad developers he is the one who can fire them.
       The opposite is not true.
      - If you have a bad tool/technology, you may end up having a lot less productivity. Are you trying to say that all tools/technologies out there are the same in this respect ? I can come up with examples.

    I give you a little credit though in the sense that SOMETIMES good developers can salvage badly managed projects.
    Also it is true that some developers are not that good (one may suggest that many), don't take pride in their work and their profesionalism, don't invest in their knowledge set, and so on. But then the project manager if he/she is really a good one should see that.
      
      But why doesn't the project manager have the ultimate responsibility for the project ?
      Collective responsibility is not a good thing.

     A good project manager should know if others don't fulfill their responsibility and take actions.
    Having collective responsibility is not a great management technique.
  10. Programmers go Extreme![ Go to top ]

    You both make points that are fair. You both take things to extremes. Reality lies somewhere inbetween.

    1) Management by comittee is a classic anti-pattern. It doesn't work. Someone has to be responsible for the project. That someone is the project manager. He is responsible to the project sponsor / client. If it fails, it's on his head.

    2) The PM is in a tough spot, because he is often under incredible pressure to build things in unrealistic time. This isn't his fault. Look at the way these projects are sold. People present sales pitches with delivery dates in them before anyone has had any real chance to look into requirements. That's the problem with internet time, and that's the reason that new internet sites are soft launched and aren't being built as quickly as they used to be. People have seen companies get burnt to the point they cease to exist.

    3) A good PM balances the pressures in (2) with the need to build a solid stable product. I personally believe that a good PM needs to be a very technical person. Otherwise he doesn't understand what his developers tell him. He also have to understand the sponsors side of things and he has to sell both his team, and the sponsors on a fair approach to the project. I have only ever met two project managers in my career that I would rate as "good." But good in this context puts you alongside minor deities! :-)

    4) Developers have a tough time. They don't get much say in deadlines. Neither for that matter do the technical leads / architects (I am lucky, but I know I'm rare.) They usually get requirements written by someone who assumed way too much business knowledge on the part of the development team. This is one of the areas where XP is good. The way XP requirements are gathered makes it go a lot smoother.

    5) Developers are lazy? Well possibly. Hiring lazy people is the fault of the hiring people. But don't make the blanket statement that they can be fired. Firing people is hard.

    6) Developers don't invest in their skill set? I agree in some cases, but investing in your skill set is a full time job these days. Unless you are lucky enough to work for a company at the leading edge (in other words your job and this activity can go hand in hand) then it's a tall order. I wish more people would read about things like EJB and then actually ask questions about the thing, rather than just start using it. If they did there would be a lot less entity beans used around the world (but that's another argument.)

    Personally, I think the main reason I have seen projects fail is that they never defined success properly. In other words, the development teams view of success differed from the project sponsors. In this area XP makes good ground, as it allows the goals to move, often and it requires everyone to play a role in defining those goals. One of the core principals is to have lots of little successes and have them often. This isn't unique to XP, but it's the very heart of the XP spirit.

    I don't think this is really an area where everyone will ever agree. Everyone has a part to play on any project, regardless of how you approach it. Bottom line. If you can't influence the outcome of the project, then you aren't needed on it.
  11. Programmers go Extreme![ Go to top ]

    Tony,

    You make good points. I agree with most of them in spirit. Except where the PM is concerned.

    The PM is actually not managing the project, you see. Most PMs don't get to determine the deadline. Nor do they get to determine the technology. Often times, they don't get to determine the staff -- especially if your CIO says, "You must hire people from this firm."

    PMs have it EXTREMELY bad. Most of the time they are built to fail from the start because they have positions of no authority. But are ultimately held responsible for the fate of the project. Tough place to be. I've done it before, and I wouldn't do it again.

    As for bad developers. Yes -- the PM is responsible for hiring. However, with the incredible demand and lack of supply, there is little a PM can do to get good talent. They have to hire 'senior' developers who actually only have had one or two years experience -- unreal. And they pay these 'seniors' incredible amounts of money as well. Talk about a lack of return on your investment.

    And ultimately, they _have_ to hire the -- even if the best candidate is mediocre. Because to NOT hire is to threaten the project itself. It is a tough situation all around. Especially when the market is demanding more talent that is available. In that situation, more than a few 'scrubs' are going to get jobs that they otherwise shouldn't even have a shot at.

    But, with all of the problems in the market, and all of the layoffs, I have hopes that the mediocre developers will just float down the river like deadwood. In more than a few cities, the market is saturated with out-of-work programmers, which means that the bad ones won't get rehired until demand dictates. I've never known a good developer who couldn't get a job -- even those who write in 3GLs.

    Its a tough problem to be sure -- and I suppose I over-generalized a little. I will compromise...

    The fault can lie with everyone, really. From the developers who are worse than ever, to the project managers who have no real control, to the senior management who expects it all to get done under those kinds of conditions.

    A project will work, if all of those areas are working well. But if one fails, the project will fail. NO weak links in this business, that's for certain.

    -- Rick
  12. Programmers go Extreme![ Go to top ]

    The link below illustrates some of the shortcomings of XP too. http://www.martinfowler.com/articles/designDead.html The point is what methodology you choose for your orgainzation depends on your orgainizations business processes or project you are working on. The article may suggest using a mix of UP (Unified programming model ) and XP to achieve the best results.
  13. Programmers go Extreme![ Go to top ]

    Since it's something I have had to deal with a lot,
    here's a question for you all - in your collective
    experience, how big a role has written/verbal communication
    skills played a role in the "average" senior developer or
    architect jobs? Was it considered an important part of the
    role, or was everyone primarily writing code all the time,
    and someone else was producing the artifacts (i.e.
    requirements etc)...?

    Just for my own curiousity ;-)

    Cory
  14. Programmers go Extreme![ Go to top ]

    The article by Martin Fowler was very insightful. However, I didn't see him mention UP (Unified Programming model) anywhere. His insight into the fact that XP provides both enabling and exploiting practices (which *both* must be present for the whole process to work) was very important.

    He did bring up some issues with respect to the appropriate use of UML, patterns and architecture. But I think there is room within XP to use these to the extent that they help.

    I whole-heartedly agree with the notion that its easier to take something that was over-engineered and reduce it to a simpler design, than to take a monolithic blob and try to partition it into a sensible architecture.

    But I find that XP's Once and Only Once (OAOO) rule combined with the You Ain't Gonna Need It (YAGNI) rule along with constant refactoring keep your code/design pretty clean.

  15. Programmers go Extreme![ Go to top ]

    http://www.arsdigita.com/asj/managing-software-engineers/
  16. Rick,

    "The fact of the matter is... if you have good programmers and good designers, then you'll have a good product. No matter what methodology is used."

    I have to strongly disagree with this statement. It simplifies things way too much.

    The whole reason Kent created XP was to fix "helpless situation": you had a good team (i.e. experienced, intelligent developers), and a decent PM, and your project STILL failed, usually due to non-technical reasons.

    XP fixes problems caused by non-technical areas such as fear, trust, and courage.

    One could suggest that "if you were competent, you'd be doing everything XP says anyway", but that's a fallacy: the most optimal solution to a set of problems is not naturally the most intuitive, or the first solution a set of intelligent/creative people will come up with. In fact, very often optimal solutions are non-trivial and take a lot of experience & experimentation to arrive at. I think XP reflects a lot of that experience & experimentation from Chrysler team and later the WikiWikiWeb where most of the intial discussion was taken during 1997-1999.

    XP's practices: constant testing, requirements (re) prioritizing, scope management, shared knowledge (i.e. the "truck factor"), burnout from overtime, over-engineering/designing, fear of changing designs when specs change, etc. are all disciplines that help improve project success by driving out fear, nudging people to have the courage to succeed, and to develop a relationship of trust between customer and developer.

  17. In an earlier post I said the PM was the name in the frame. I know someone said that this was not the case. To be honest, I agree with what they said. The PM doesn't usually get a say in much, he just has to deliver what is already comitted.

    However, I wasn't talking about how it should be, I was talking about how it is. Whether he got a say or not, the PM IS the person that gets it in the neck if the thing fails, even if it was Mission: Impossible to start with! That's not right, it's not fair, but it is true in most cases.

    Where XP is good is that it keeps the channels of communication much more open between the development team and the users.

    On a project I recently lead from a technical perspective, we didn't use XP. Well, we used half of it. XP was too much for the client to handle. The part we did use was constant, honest, open communication with the client. Even when the news was not good.

    This was, to use their own words "a breath of fresh air." They were so used to having to mistrust consultants they really liked the communication. They were allowed to change their mind, but they had to accept that changing their mind sometimes meant they had to change their dates as well. The main thing we were driving into more junior people was that it is OK to say "I don't know." Admitting that is halfway towards solving the problem. You are then able to ask the users the questions you need to solve the problem. They know why you're asking and they want to help.

    This is where XP is really strong. Don't view it so much as a methodology. It's about dealing with people. That's where it really differs from other approaches. As an earlier mail said, this is about fear. Peoples' fear. This is a people business. Ignore the fact we write software right now. The resulting way of working is the result of the approach, not the approach itself.

    In my career I have worked with too many people that wouldn't say "I don't know." This meant they had to try and get information out of the client without them realizing it. How unproductive. The "story card" approach of XP just makes that a thing of the past, but people don't really notice it's happening, so they don't get worried about it.

    This is, of course, just my opinion! :-)
  18. In an earlier post I said the PM was the name in the frame. I know someone said that this was not the case. To be honest, I agree with what they said. The PM doesn't usually get a say in much, he just has to deliver what is already comitted.

    However, I wasn't talking about how it should be, I was talking about how it is. Whether he got a say or not, the PM IS the person that gets it in the neck if the thing fails, even if it was Mission: Impossible to start with! That's not right, it's not fair, but it is true in most cases.

    Where XP is good is that it keeps the channels of communication much more open between the development team and the users.

    On a project I recently lead from a technical perspective, we didn't use XP. Well, we used half of it. XP was too much for the client to handle. The part we did use was constant, honest, open communication with the client. Even when the news was not good.

    This was, to use their own words "a breath of fresh air." They were so used to having to mistrust consultants they really liked the communication. They were allowed to change their mind, but they had to accept that changing their mind sometimes meant they had to change their dates as well. The main thing we were driving into more junior people was that it is OK to say "I don't know." Admitting that is halfway towards solving the problem. You are then able to ask the users the questions you need to solve the problem. They know why you're asking and they want to help.

    This is where XP is really strong. Don't view it so much as a methodology. It's about dealing with people. That's where it really differs from other approaches. As an earlier mail said, this is about fear. Peoples' fear. This is a people business. Ignore the fact we write software right now. The resulting way of working is the result of the approach, not the approach itself.

    In my career I have worked with too many people that wouldn't say "I don't know." This meant they had to try and get information out of the client without them realizing it. How unproductive. The "story card" approach of XP just makes that a thing of the past, but people don't really notice it's happening, so they don't get worried about it.

    This is, of course, just my opinion! :-)
  19. Programmers go Extreme![ Go to top ]

    Here is an interesting paper on pair programming. I think the comparison with 'line-of-sight' apprenticeship training and 'expert-in-earshot' management is very enlightening. Check it out.

    http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
  20. Programmers go Extreme![ Go to top ]

    Yeah it is amazing that there is even a bandwagon for this.
    Most military/FAA software companies were using strict
    software processes for many years before anyone ever heard
    of Extreme Programming - it is just one of the many process
    philosophies out there. It's great that XP is popular, but
    it's sad that it seems at all radical.

    Unfortunately, the vast majority of software managers still
    think that only time spent writing code is valuable -
    IMHO that's the real problem. Think about that one - Fred
    Brook's "Mythical Man-Month" was written in the 70's and
    is still under-read today. It should be required reading.
  21. Programmers go Extreme![ Go to top ]

    In my experience, most managers seem to think time programming time lost. Projects spent months in functional design, then weeks in technical design, leaving only days for coding and testing. They are extremely surprised that the project fails to deliver because the coding takes longer than they anticipated. The next project spends even more time in design, because the management consultant hired to analyse the failure decided that the design was not clear enough...
  22. Programmers go Extreme![ Go to top ]

    Interestingly enough, that is where XP is most effective. It is pretty lightweight compared to other heavyweight methodologies such as RUP. Again just like RUP it is iterative in nature, thus giving a good understanding about risk associated with the project. Also I find pair programming an excellent concept although it becomes slightly difficult to explain the manager that coding in pairs doesn't necessarily lead towards reduced productivity. My experience says that processes always help no matter how much we developers dislike them. They are a boon for managers!