Discussions

News: It's NOT the code, stupid!

  1. It's NOT the code, stupid! (41 messages)

    Dan Creswell has commented to Fabrizio Giudici's blog entry, "Where are we going?," with an insightful comment. Mr. Guidici's main point:
    [Does anyone] think that having closures or the -> operator for properties or a neat integration with a scripting language will decrease significantly the rate of failed projects? Or will significantly increase the quality of our work, and the quality of services delivered to customers? ... My answer is a resounding "no." Having better tools is important, but the key to success is another thing: the process. Which contains stuff such as team building, a good communication plan with the customer, good risk assessment strategies (including thinking of "b-plans"), good design skills, knowledge of the technology, testing.
    Dan Creswell directed some focus in yet another area in his comment:
    We need to get our head out of the code! By which I mean we should spend more time at the 10000ft view in respect of not just tools but architecture and other considerations beyond just getting our hands dirty in the code. These higher level topics are the ones where we get to drive biggest change and improvement. Which maybe explains why we've actually progressed so little in recent times.
    It's a worthwhile point. Many projects get bogged down in trying to fit their projects' architectures into a limited set of APIs simply because they don't know what their alternatives are, and seeing things from the high-level view (where the actual moving parts are obscured) can make it easier to look at what is actually required from an architecture standpoint, which in turn makes it easier to find specific technologies that fulfill those requirements, instead of deciding that you have a bolt and a hammer; time to hammer away! Incidentally, Mr. Guidici followed his post with an amusing (and illuminating) photographer's joke:
    A pro has been invited to dinner by some friends and he's showing some premium-winning photos from his portfolio. During the dinner the hostess comments "Hey, these photos are really cool, you must have a very good camera!". He replies: "Definitely. BTW, this dish is excellent: you must have a very good pot".

    Threaded Messages (41)

  2. Re: It's NOT the code, stupid![ Go to top ]

    The problem most of the time isn't process, it's too much process. Specifically: processes made up by a committe of managers with absolutely no grasp whatsoever of what software development is about. Too often project fails because of over-beaurocratic processes with no accountability, lots of design by committe and an over-belief in a magic process being able to deliver a project even if you have retarded monkeys doing the job. Well, surprise, _people_ will deliver a project, not a process. Good people will find the appropriate ways to manage risk, communicate and deliver without getting banged over the head with a silver-bullet process. Retarded monkeys however will never deliver anything but piles of useless documents, regardless of what process is used.
  3. Re: It's NOT the code, stupid![ Go to top ]

    The problem most of the time isn't process, it's too much process. Specifically: processes made up by a committe of managers with absolutely no grasp whatsoever of what software development is about.

    Too often project fails because of over-beaurocratic processes with no accountability, lots of design by committe and an over-belief in a magic process being able to deliver a project even if you have retarded monkeys doing the job.

    Well, surprise, _people_ will deliver a project, not a process. Good people will find the appropriate ways to manage risk, communicate and deliver without getting banged over the head with a silver-bullet process. Retarded monkeys however will never deliver anything but piles of useless documents, regardless of what process is used.
    I've been there but the developers were actually talented but they are being forced to use the retarded monkey process which basically negated their skills. The people coming up with the process were actually the retarded monkeys. They introduced a process where the result was more costly and no more reliable. A normal person would think that the process needed to retooled, right? Instead the developers were blamed for not doing the process right and another process was introduced to make sure the original was followed and so on and so forth. Eventually they said, "Wow, development is so expensive! Let's outsource it."
  4. Re: It's NOT the code, stupid![ Go to top ]

    I've been there but the developers were actually talented but they are being forced to use the retarded monkey process which basically negated their skills. The people coming up with the process were actually the retarded monkeys. They introduced a process where the result was more costly and no more reliable. A normal person would think that the process needed to retooled, right? Instead the developers were blamed for not doing the process right and another process was introduced to make sure the original was followed and so on and so forth. Eventually they said, "Wow, development is so expensive! Let's outsource it."
    Been there, and absolutely agree.. Its the blind faith in "The Process", they think if only people follow it, everything will be ok. If talented people are having their skills being under-leveraged by a stupid processes, unfortunately most of the time, the only viable option is to start keeping an eye out for a new job, because as you say it is very rarely that the PHB's behind the retarded process are the ones to get the blame.
  5. Re: It's NOT the code, stupid![ Go to top ]

    In my experience it has not been so much that the process is stupid as much as it is empty, incomplete and/or ambiguous. The process tells you to produce an artifact but it doesn't tell you how to produce a good one and there is nothing in place that insures the artifact is good and, therefore, useful. It does not tie the content of the artifact to those who are supposed to consume it. What I often see is documents that could have been useful but aren't because the consumers of the document were not consulted. Complicating things are literal-minded bureaucrats who impede project-level customizations - that is more often the stupid part. An example of a stupid process to me would be one that mixes methodologies and paradigms and constrains reasonable project-level customization. For example, do incremental development, but produce waterfall documentation, and you can do OOA and OOP but you must include the artifacts of functional decomposition and structured analysis. Our profession has for decades told us that when designing a system start with the requirements (end state) and work backwards so that there are not unnecessary inputs or artifacts produced. Everything must be traceable to the requirements which are defined in terms of the system's actors (consumers). Yet, our processes are rarely designed in the same way. In other words, in order to insure that an artifact is useful, I need to consult with its consumers. Why would you begin defining a process by starting at the beginning - what you can do - instead of the end - what you must do? The "retarded monkeys" you refer to are clearly not capable of designing anything, much less a process. So why don't developers participate more in process design? I wouldn't hand them control of the whole thing since developers have a limited view as well. We are not the only consumers of the documentation. All the stakeholders must participate. I don't see a lot of us volunteering so I guess it is left to the "retarded monkeys". I'm guilty too. We can’t seem to trust something this important (process definition and management) to the people who actually enjoy doing it.
  6. Re: It's NOT the code, stupid![ Go to top ]

    We need to get our head out of the code!

    By which I mean we should spend more time at the 10000ft view in respect of not just tools but architecture and other considerations beyond just getting our hands dirty in the code.
    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write. I agree that we should be looking at the system from a higher level but a higher-level language helps a lot with this. I'm not saying you can't take high-level design and convert it into low-level code. But bridging the gap takes a lot of experience and even then you can get off-track easily (and sometimes completely lost.) In any event I think that all the code generation being used in the Java world today is a real sign that the language is not meeting the needs of developers. Essentially, people are using many meta-languages and treating Java like it's an assembly language. On the other hand, I think trying to make Java into a something it's not might not be a great idea either. I've had a good amount of success with languages that run on the JVM and can work with Java classes. It seems like this is a better way forward than greatly increasing the complexity of Java.
  7. Re: It's NOT the code, stupid![ Go to top ]

    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.
    If there's so much code to write is that because you've got the wrong design perhaps? Wrong tools? Impossible requirements? Something else? Only way you'll know is to get your head out of the code....
  8. Re: It's NOT the code, stupid![ Go to top ]


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.


    If there's so much code to write is that because you've got the wrong design perhaps? Wrong tools? Impossible requirements? Something else?

    Only way you'll know is to get your head out of the code....
    Why can't I take the code up 10k feet?
  9. Re: It's NOT the code, stupid![ Go to top ]


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.


    If there's so much code to write is that because you've got the wrong design perhaps? Wrong tools? Impossible requirements? Something else?

    Only way you'll know is to get your head out of the code....
    I think you are missing the point. If you were asked to build a rocket capable of reaching escape velocity with only common common eating utensils (e.g. forks, spoons, chopsticks) as tools, what are your chances of success? This is an absurd example but clearly, tools matter. The designers of Java have a goal of making Java popular. Why shouldn't they consider how to improve it? And why shouldn't those with a lot of time and code invested in Java want a say in where it goes? I've never been on a project with unlimited time. You can sit around and think of better processes but at some point you have to start doing something. If it takes a lot of time to code, you have less time to spend at 10 thousand feet. The whole idea that the code is unimportant leads to a lot of failures. It also leads to a ridiculous situation where the 'architects' sit around and think up vague designs and then the developers have to fill in all the blanks, doing the architect's job and their own. Because the architect is never involved with the actual implementation, they never realize the errors they made and the cycle repeats itself indefinitely.
  10. Re: It's NOT the code, stupid![ Go to top ]

    The whole idea that the code is unimportant leads to a lot of failures. It also leads to a ridiculous situation where the 'architects' sit around and think up vague designs and then the developers have to fill in all the blanks, doing the architect's job and their own. Because the architect is never involved with the actual implementation, they never realize the errors they made and the cycle repeats itself indefinitely.
    That's why as an architect I believe it is vital that I remain hands-on and continue to do at least some of the coding on my projects. Otherwise I'd become out of touch and would not be able to effectively communicate with my developers. But to the larger point which you indirectly make when you refer to "vague designs" which leave the developers to do the architect's job and their own. In broken development developers are usually also doing the analysts/modeler's job and the customer's job too. (These folks have often been cut - to "save" time and/or money.) It is why a lot of projects fail. Not doing the up front work thoroughly and well (requirements, architecture,design, test plans) before jumping into the code guarantees that the coding and the project will take longer and have less chance of success. If the up front things are taken care of, coding becomes more of a typing exercise than an extended brain cramp. One of the things the upfront work should do for you is to recognize all of the distinct problems to be solved and solution patterns to apply so each problem is solved only one time. In all too typical development the same problems are being solved at the same time by different developers. While coding it is too easy to focus on the details of a single tree or even small difference between trees and miss the forest. That is why it is important step back and study the problem before diving in. Personally, I like to spend some time by the pool with a pencil and legal pad working things out before getting started. If only my employer would put in a pool.
  11. Re: It's NOT the code, stupid![ Go to top ]


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.


    If there's so much code to write is that because you've got the wrong design perhaps? Wrong tools? Impossible requirements? Something else?

    Only way you'll know is to get your head out of the code....


    I think you are missing the point. If you were asked to build a rocket capable of reaching escape velocity with only common common eating utensils (e.g. forks, spoons, chopsticks) as tools, what are your chances of success? This is an absurd example but clearly, tools matter. The designers of Java have a goal of making Java popular. Why shouldn't they consider how to improve it? And why shouldn't those with a lot of time and code invested in Java want a say in where it goes?
    Because not everything is best solved from the code perspective. No one said that tools don't matter just that there's lots of other stuff that matters as well. Also, I personally don't want to see the designers focus on making Java popular I want them to make it better! If that leads to greater popularity, fine. One of the things the Rails team do well is to focus on better not popular - in fact, that's one of DHH's key principles. Linus Torvalds has a similar attitude.
    I've never been on a project with unlimited time. You can sit around and think of better processes but at some point you have to start doing something. If it takes a lot of time to code, you have less time to spend at 10 thousand feet.
    If you haven't thought about things from a higher viewpoint how do you know how long something is going to take to code? Why have you got lots to code? Perhaps because you didn't think long enough and pick a good solution? Look before you leap? No one is saying you have unlimited time just that limited time does not translate into "code like mad, don't bother thinking".
    The whole idea that the code is unimportant leads to a lot of failures. It also leads to a ridiculous situation where the 'architects' sit around and think up vague designs and then the developers have to fill in all the blanks, doing the architect's job and their own. Because the architect is never involved with the actual implementation, they never realize the errors they made and the cycle repeats itself indefinitely.
    No one said code is unimportant just that it's importance is over-rated. No one said that an architect shouldn't pay attention to the consequences for the code that's bad architecting. But code doesn't drive everything - it is the product of everything else. Closures might save a line or two of code. Removing the need for a particular component through architectural revision can save thousands of lines of code.
  12. Re: It's NOT the code, stupid![ Go to top ]


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.


    If there's so much code to write is that because you've got the wrong design perhaps? Wrong tools? Impossible requirements? Something else?

    Only way you'll know is to get your head out of the code....


    I think you are missing the point. If you were asked to build a rocket capable of reaching escape velocity with only common common eating utensils (e.g. forks, spoons, chopsticks) as tools, what are your chances of success? This is an absurd example but clearly, tools matter. The designers of Java have a goal of making Java popular. Why shouldn't they consider how to improve it? And why shouldn't those with a lot of time and code invested in Java want a say in where it goes?


    Because not everything is best solved from the code perspective. No one said that tools don't matter just that there's lots of other stuff that matters as well.
    And (again) better tools give you more time to do those other things.


    Also, I personally don't want to see the designers focus on making Java popular I want them to make it better! If that leads to greater popularity, fine. One of the things the Rails team do well is to focus on better not popular - in fact, that's one of DHH's key principles. Linus Torvalds has a similar attitude.
    Did I not say improve? [checking] Yes, I did.

    I've never been on a project with unlimited time. You can sit around and think of better processes but at some point you have to start doing something. If it takes a lot of time to code, you have less time to spend at 10 thousand feet.


    If you haven't thought about things from a higher viewpoint how do you know how long something is going to take to code?
    How do you get 'not think at all' out of 'at some point you have to start doing something'?
    Why have you got lots to code? Perhaps because you didn't think long enough and pick a good solution?

    Look before you leap? No one is saying you have unlimited time just that limited time does not translate into "code like mad, don't bother thinking".
    Right, I am not arguing that you should. I believe the exact opposite. I disagree that the tools you use are not a factor. If you don't have time to think about whether you are using the right tool, you don't have time to realize you are using the wrong one.
    But code doesn't drive everything - it is the product of everything else.
    Show me where I said it does.
    Closures might save a line or two of code. Removing the need for a particular component through architectural revision can save thousands of lines of code.
    Closures do more than allow you to remove a line of code here and there. They allow for things that you cannot do with an anonymous inner class. The most important thing is that they make it easier to use approaches that are much more effective and save a lot of code all around. People who don't use this type of approach don't realize how clumsy anonymous classes can be. The general approach in Java has become a dreadnought approach. Java developers, on a whole write way more code than is necessary. As a result they have little time to think about what they are doing because they don't have time. But again, I don't know that all the things they are considering for 1.7 are worth the added complexity. Generics in 1.5 added a lot of complexity. What I wish they would add is function pointers because it would make it easier to integrate with dynamic languages running on the JVM. For example in Jython, you have to write a class just so you can pass a method to a Java application. If Java supported method pointers, I could just pass in the method and be done with it. It doesn't seem like much but this kind of thing is what makes developers avoid these types of designs.
  13. Re: It's NOT the code, stupid![ Go to top ]

    I think you are missing the point. If you were asked to build a rocket capable of reaching escape velocity with only common common eating utensils (e.g. forks, spoons, chopsticks) as tools, what are your chances of success?
    You've obviously never watched MacGyver. Peace, Cameron Purdy Tangosol Coherence: Clustered Caching for Java
  14. Re: It's NOT the code, stupid![ Go to top ]

    I think you are missing the point. If you were asked to build a rocket capable of reaching escape velocity with only common common eating utensils (e.g. forks, spoons, chopsticks) as tools, what are your chances of success?


    You've obviously never watched MacGyver.
    That show went downhill really early. I think after the episode where he shot his swiss-army knife out of a homemade bazooka powered with mothballs and something else, they started running out of ideas. I also remember him defusing a bomb on a cruise ship with milk.
  15. Re: It's NOT the code, stupid![ Go to top ]

    We need to get our head out of the code!

    By which I mean we should spend more time at the 10000ft view in respect of not just tools but architecture and other considerations beyond just getting our hands dirty in the code.


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.

    I agree that we should be looking at the system from a higher level but a higher-level language helps a lot with this. I'm not saying you can't take high-level design and convert it into low-level code. But bridging the gap takes a lot of experience and even then you can get off-track easily (and sometimes completely lost.)

    In any event I think that all the code generation being used in the Java world today is a real sign that the language is not meeting the needs of developers. Essentially, people are using many meta-languages and treating Java like it's an assembly language.

    On the other hand, I think trying to make Java into a something it's not might not be a great idea either. I've had a good amount of success with languages that run on the JVM and can work with Java classes. It seems like this is a better way forward than greatly increasing the complexity of Java.


    This is sort of a never-ending cycle. "Your recommendation on is all well and good in theory but it doesn't fix *my* problem with ! Which may be true, but is also somewhat besides the point. In the end, we know that nothing can be done without good people. And we know that bad mgmt can make getting good work done pretty much impossible. And we know that bad tools make the work much, much harder. The discussion of which problem is most important really depends on which one is biting any one of us at a given moment and strikes me as being rather unfruitful. Back to the 10K foot view -- I 100% agree with this point. First and foremost, we need to have a clear understanding of the goals of a project and the building blocks we're using. More and more, large system development needs a focus on architecture to be sucessful. Good tools are part of this process by helping control the amount of low-value plumbing code that must be designed and written by people. This doesn't treat Java as an assembler; instead, a good tool acts like a meta-framework by providing good automated support for the specific frameworks we're trying to use in our systems. Good process is also important, and at least competent people are a requirement. And in the presence of bad mgmt, the whole exercise is rather like the old "If a tree falls in ehe forest and no one is there to hear it, does it still make a sound?" To which I believe the right answer is "Who cares?" :)
  16. Re: It's NOT the code, stupid![ Go to top ]

    I agree that we should be looking at the system from a higher level but a higher-level language helps a lot with this. I'm not saying you can't take high-level design and convert it into low-level code. But bridging the gap takes a lot of experience and even then you can get off-track easily (and sometimes completely lost.)

    In any event I think that all the code generation being used in the Java world today is a real sign that the language is not meeting the needs of developers. Essentially, people are using many meta-languages and treating Java like it's an assembly language.

    On the other hand, I think trying to make Java into a something it's not might not be a great idea either. I've had a good amount of success with languages that run on the JVM and can work with Java classes. It seems like this is a better way forward than greatly increasing the complexity of Java.
    Java is not perfect but I don't see how you can realistically blame the language here. Java has a plethora of high-level constructs. Does it have every one imaginable? No. Should it? No. Kitchen-sink language design leads to a utter mess. One must weigh (1) the speed and convenience of the developer writing the code vs. (2) the efficiency of the many other developers who have to use, understand, troubleshoot, maintain, and extend over its life. Java does pretty well at this currently. Dynamic languages seem to do well at (1) and not very well at (2). Do we need to consider every problem with dynamic language constructs? No. What's wrong with good old well designed libraries (especially given annotations to leverage)? I think the problem is not the language -- its developers who look at every problem and imagine that they need the full J2EE spec, plus several other frameworks and a full understanding of the all of that to screw in a lightbulb. Back to the topic at hand, part of the reason for this is design process gone awry. The process management types won't be able to fix this, though, as they don't understand design...
  17. Re: It's NOT the code, stupid![ Go to top ]

    I agree that we should be looking at the system from a higher level but a higher-level language helps a lot with this. I'm not saying you can't take high-level design and convert it into low-level code. But bridging the gap takes a lot of experience and even then you can get off-track easily (and sometimes completely lost.)

    In any event I think that all the code generation being used in the Java world today is a real sign that the language is not meeting the needs of developers. Essentially, people are using many meta-languages and treating Java like it's an assembly language.

    On the other hand, I think trying to make Java into a something it's not might not be a great idea either. I've had a good amount of success with languages that run on the JVM and can work with Java classes. It seems like this is a better way forward than greatly increasing the complexity of Java.


    Java is not perfect but I don't see how you can realistically blame the language here.

    I'm not blaming the language. I'm saying that there is a disconnect between what people are trying to do with Java and what is natural in Java which is why we have things like Spring.
    Java has a plethora of high-level constructs. Does it have every one imaginable? No. Should it? No. Kitchen-sink language design leads to a utter mess. One must weigh (1) the speed and convenience of the developer writing the code vs. (2) the efficiency of the many other developers who have to use, understand, troubleshoot, maintain, and extend over its life. Java does pretty well at this currently.
    I think it pretty well at 2, but not so well at 1. I don't that you couldn't improve 1 without hurting 2.
    Dynamic languages seem to do well at (1) and not very well at (2).

    Do we need to consider every problem with dynamic language constructs? No. What's wrong with good old well designed libraries (especially given annotations to leverage)?
    Closures and function pointers are not restricted to dynamic languages. They can be staticly typechecked. But your point about dynamic languages doing well at code efficiency is exactly right on. That's why I think using dynamic languages in conjunction with static languages has a lot of potential. Why do we feel a system must be all one or all the other? Paraphrasing you, we should not consider every problem with dynamic language constructs. Likewise, we should not consider every problem with static language constructs. There's no one size fits all model. I don't think there will ever be. But closures and function pointers are neither of these. They make using functional constructs easy and natural. Functional approaches are superior to imperative approaches for many problems but like the above concepts, they are not a good fit for everything. Again, the all or nothing model is what we have lived with for years.
    I think the problem is not the language -- its developers who look at every problem and imagine that they need the full J2EE spec, plus several other frameworks and a full understanding of the all of that to screw in a lightbulb.
    I agree, but they believe that because that's what they were told by Sun and all the 'gurus' of yesteryear. Now everyone thinks they need Spring and hibernate and 'pojos' (a.k.a JavaBeans.) How is it any different?
    Back to the topic at hand, part of the reason for this is design process gone awry. The process management types won't be able to fix this, though, as they don't understand design...
    I agree here too. I think a major problem is that there are too many non-technical (or semi-technical*) people micro-managing technical teams. I've seen over and over that they are bringing in a lot of hifalutin ideas from their latest issue of CTO quarterly but don't take any time to actually figure out what is going on out on the 'floor'. Every year there's a new buzzword that will solve all the problems. It was OO, then n-tier, now it's SOA. Not that these things have no merit, it's that these people don't understand what these things really mean and what they do and don't provide. *semi-technical manager - a manager that used to code but was moved into management to limit the damage they were causing.
  18. Re: It's NOT the code, stupid![ Go to top ]

    *semi-technical manager - a manager that used to code but was moved into management to limit the damage they were causing.
    Hmmm. How do you know about where I work? :)
  19. Re: It's NOT the code, stupid![ Go to top ]

    *semi-technical manager - a manager that used to code but was moved into management to limit the damage they were causing.
    It rules:) As for code... Really you sell code. If it doesn't work you won't sell it (there are still some variations about it:)) And agree with:
    There must be different roles and responsibilities in the team. Borderlines between roles may be somewhat fuzzy, but the leading role must be clearly defined. The project leader/architect must code too (in facts I code a lot, I usually don't believe in architects who don't code) but his main responsibility is to take decisions.
    Every person should his job. Anyway, right process of defining business and other requirements is very important otherwise it can easily lead project to fail. Language is a tool but with wrong tool or wrong usage of tool can cause all things to go wrong. Assuming all this developer should be concerned about tools. Top manager should be concerned about business. And Middle tier is about how to put it together:) I like this thread. Thanks to all
  20. Re: It's NOT the code, stupid![ Go to top ]

    Closures and function pointers are not restricted to dynamic languages. They can be staticly typechecked. But your point about dynamic languages doing well at code efficiency is exactly right on. That's why I think using dynamic languages in conjunction with static languages has a lot of potential. Why do we feel a system must be all one or all the other? Paraphrasing you, we should not consider every problem with dynamic language constructs. Likewise, we should not consider every problem with static language constructs. There's no one size fits all model. I don't think there will ever be.
    Go take a look at the Groovy thread posted a few days back. I think it is moving towards being a hybrid language, where static analysis and optimization are performed where static structures are available but the developer is free to use dynamic features.
  21. Re: It's NOT the code, stupid![ Go to top ]

    Go take a look at the Groovy thread posted a few days back. I think it is moving towards being a hybrid language, where static analysis and optimization are performed where static structures are available but the developer is free to use dynamic features.
    I'll check it out when I get a chance. Groovy does seem more appealing now that it's out as a full release and not a 0.x version. And since it's going to be part of the SDK, it'll be a much easier thing to sell to people than Jython or JRuby. I think that in order to make this kind of hybrid approach really work, APIs will need to more functional-esque in their designs that has been true in the past. That's where function pointers need to fit into Java IMO.
  22. Re: It's NOT the code, stupid![ Go to top ]

    We need to get our head out of the code!

    By which I mean we should spend more time at the 10000ft view in respect of not just tools but architecture and other considerations beyond just getting our hands dirty in the code.


    The problem with this argument is that a lot of developers can't get their heads out of the code because there is so much to write.

    I agree that we should be looking at the system from a higher level but a higher-level language helps a lot with this. I'm not saying you can't take high-level design and convert it into low-level code. But bridging the gap takes a lot of experience and even then you can get off-track easily (and sometimes completely lost.)

    In any event I think that all the code generation being used in the Java world today is a real sign that the language is not meeting the needs of developers. Essentially, people are using many meta-languages and treating Java like it's an assembly language.

    On the other hand, I think trying to make Java into a something it's not might not be a great idea either. I've had a good amount of success with languages that run on the JVM and can work with Java classes. It seems like this is a better way forward than greatly increasing the complexity of Java.
    Meta-language isn't the right word. Domain-Specific Language is more like it, and it indicates all the failings. It's specific to one application, it becomes a foreign language that has to be learned. The balkanization of web frameworks is directly related to this, since each and every one of them invents their own DSL to handle/speed up/make convenient the presentation layer's text processing: JSP tag libraries (each their own DSL! bonus!), JSP-EL, MVEL, Velocity, OGNL, XSP, or Groovy/BeanShell/JRuby scripts, etc etc etc. I don't think Java needs to transform to accomodate those, but the failings of the language led to the current situation. Variety is good...to a point. But the point of code generation indicating major problems is dead on, especially the metaphor of Java becoming an assembler endpoint for the Domain-Specific Languages/Code Generators. Annotations are the latest DSL tool for handling Java's failings. Like JSP tags embedded in the code. The accessor/mutator generation in Java is ridiculous. No matter how much tooling is done to support it, the presence and process of generating of braindead accessors and mutators is a ridiculous overhead. Seriously, we think closures are the magic bullet, but we've wasted man-decades or man-centuries in the Java community generating braindead accessors. And exception/try/catch scoping shouldn't be as strict as it is. Having to continually declare variables outside the main try-catch block so I can do cleanup in the catch or finally clause is annoying as hell. Tooling is an issue in every single language, and dotNET and Java are at the forefront since they are the most mature. Java has passed C and C++ due to the platform balkanization compliation introduces. Between Maven, Ant, and Eclipse, and the numerous side projects associated with them, Java has fantastic tooling that is just getting better and better. Ultimately the main "Not the code stupid" is like most of my posts on this site - trying to hijack a discussion for a different one. Of course, I do it in the comments. This is doing it in a story. It's two different issues: - Java needs improvement - tooling needs to proceed Java has even introduced features to support your tooling. The direct-bytecode manipulation and generation of some frameworks. Annotations (despite all my reservations about them). Hotswap code (such that it works). And now, alternate scripting platforms (although that would introduce a threat of balkanization). The common API/code libraries.
  23. It's the PEOPLE, stupid![ Go to top ]

    The following article by Alistair Cockburn from 1999 still rings more true today than any other article I've ever read regarding the success/failure of projects: Characterizing people as non-linear, first-order components in software development This is not to say that process, tools, frameworks, etc don't play a part in the success/failure of a project. They do. However, it is amazing how many projects ignore the crucial fact that it is the people on the projects that have a very significant impact and arguably the most significant impact on the success/failure of a project (with the Mythical Man Month being an extreme example of this disregard for the people).
  24. Re: It's the PEOPLE, stupid![ Go to top ]

    The following article by Alistair Cockburn from 1999 still rings more true today than any other article I've ever read regarding the success/failure of projects:

    Characterizing people as non-linear, first-order components in software development
    +1
  25. "Its the blind faith in "The Process", they think if only people follow it, everything will be ok."
    The point is that people should not follow the process, but lead it. In my quoted post I said that people should be the focal point, instead of tools (in the end the process is just another tool, like code - but IMHO is more critical than code). I agree: there's no silver-bullet process, in facts I'm advocating UP, XP, Agile or whatever. Being just a tool, people should know various processes and decide to use a mixture of them to their advantage, helping also with good sense and intuition. I see various processes as extrema points, and you have to choose where you sit in the middle of them. The optimal mix depends on people (both customer and provider) attitude and context.
    "Good people will find the appropriate ways to manage risk, communicate and deliver without getting banged over the head with a silver-bullet process. Retarded monkeys however will never deliver anything but piles of useless documents, regardless of what process is used.
    Yes. The point is that there are different people roles in the project: architect, manager, leader, designer, developer. What worries me is that in these debates I always read "developers" - which is just the same objection as Dan who says there's too much emphasys on "code". Then, there will be always good people and retarded monkeys - but with education we could have less retarted monkeys and even better people. The point is that education can't be done if we only talk about code.
  26. ... in facts I'm NOT advocating ...
  27. Re: It's NOT the code, stupid![ Go to top ]

    The point is that education can't be done if we only talk about code.
    or are only allowed to talk about the code.
  28. Re: It's NOT the code, stupid![ Go to top ]

    But who's preventing us from talking of other things? My vision is that: a) dumb people who only studied on books are not constrained by code, but they usually lose the contact with reality, as Dilbert's boss. b) Smart people are the ones that have been raised with milk and code, but it's probably a fault of them if they get trapped within it even when they grow up.
  29. Re: It's NOT the code, stupid![ Go to top ]

    But who's preventing us from talking of other things?
    By exclusion. We are not involved until it is time to code the data entry screens.
  30. Who cares about projects?[ Go to top ]

    The last time I looked, none of my languages had any support for status reports, gantt charts, milestones, configuration management. Nope, just loops, functions, objects, variables, and so on. You know, the crazy sort of thing you expect to see in a *language*. Why must every modification to the Java *language* be viewed through the lens of how much ROI it will return on our cross-functional leveraged synergistic orchestrated business process enterprise management? Why can't an addition to the language simply be "because it's expressive and powerful and frankly everything else people are using has something similar".
  31. Re: Who cares about projects?[ Go to top ]

    The last time I looked, none of my languages had any support for status reports, gantt charts, milestones, configuration management. Nope, just loops, functions, objects, variables, and so on. You know, the crazy sort of thing you expect to see in a *language*.

    Why must every modification to the Java *language* be viewed through the lens of how much ROI it will return on our cross-functional leveraged synergistic orchestrated business process enterprise management? Why can't an addition to the language simply be "because it's expressive and powerful and frankly everything else people are using has something similar".
    In facts we aren't criticizing people adding features to the language, but the IMHO excessive expectations that the community seems to have about these features. For what concerns the ROI, unfortunately we're talking about a job and ROI can't but play a key role. If I hadn't to earn money for a living I'd be doing something totally different, maybe involving software all the same, but in totally different way :-) For what concerns "everything else people are using has something similar", fortunately the guys at Sun weren't driven by this concept eleven years ago. :-)
  32. Re: Who cares about projects?[ Go to top ]

    In facts we aren't criticizing people adding features to the language, but the IMHO excessive expectations that the community seems to have about these features.
    That wasn't clear to me from your blog. That's a fair point. I just see closures and/or function pointers as not punishing people for using effective approaches. I think Java makes it easy to do things the dumb way. Code that is written using inner classes, anonymous inner classes, and local classes looks scary to people. For example, Eclipse rolls up these classes by default. You have to expand them to see what they do. To me, this is evidence that these types of approaches are seen as hacks, second-class citizens in the Java world. People use them as the exception, not the rule. They should be the rule and public classes the exception. Hardly anyone seems to get this.
  33. reverse fit[ Go to top ]

    Next thing what happens is that you shape the projects to the process, a vicious cycle: 1. The process will produce fine grained technical specs where each item is linked back to a requirement 2. It is detailed and complete so everyone can implement it. 3. All good developers we have are overloaded by spec writing, so we need cheap resources to hack it in 4. Offshore resources are the cheapest 5. The long cycle requires a waterfall model or at least long iterations (>6 months) 7. = 1. The entry-point is the spec-mania which comes from process design: The design goal is to have tracability on every level. The tracability needs to be formalized - what kind of process would you have otherwise? Of course a project needs to be managed, so we have to keep the managed units simple, thus the taylorism to decompose and specialize - which is actually a divide&conquer. This approach should value each step in the work chain equally, but in reality it is assigning the coding the least important role. In the end it is the code that gets executed - not the specs and test-plans. My understanding of Agile is that this distortion is corrected; and this has to be driven by developers as it seems that (nearly) anyone can be learn accounting as fewer excel in programming
  34. First, a small step ...[ Go to top ]

    Personally, I think the first step is to get a lot of todays developers to really understand what analysis and design are. Sure they are "doing them" as they code (since there is no way around them really) but a lot developers IMHO don't seem to really understand what analysis and design are about. I believe if more developers had a better understanding of what analysis and design are they would realise that they couldn't do them whilst they were coding and that code is not the best way to represent the results of analsyis and design (and may even then understand what UML is for). From there would come an understanding of the need for process, to coordinate these separate and important tasks, and the realisation that (pure) coding itself is the least important part of development. All this, of course, is within an incremental and iterative approach to development. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com
  35. When the project is over ....[ Go to top ]

    When the project is over, what is left is the running code. The produced value, is in the running code. So, yes, the process is the center, but its ultimate goal is to produce the code. Maurizio
  36. Re: First, a small step ...[ Go to top ]

    From there would come an understanding of the need for process, to coordinate these separate and important tasks, and the realisation that (pure) coding itself is the least important part of development. All this, of course, is within an incremental and iterative approach to development.
    Most processes try to formally divide things into separate formally defined deliverables that can be tossed over the wall to someone else (e.g. outsourced or sent to another division for completion with minimal further communication). Breaking analysis, design, and coding apart in this way is counter to any form of agility as all three should be done in tight iterative loops -- at least until a certain level of issues are worked out. Most processes tend to force an unnatural, inefficient work mode for the benefit of those in management who want more milestones to track the project on, etc.
  37. Re: First, a small step ...[ Go to top ]

    I'm all for incremental and iterative, agile and all. However, if anyone thinks analysis deliverables are the same as design deliverables and all can be represented in code then I think they don't really understand analysis and design. When a developer says that they do analysis and (anything but low-level) design whilst coding, for me at least, is a red flag indicating that they probably aren't doing analysis and design well. Yes, these can be done in a tight iteration (although there is benefit in doing more than a small bit of analysis and design at a time, just as there is for coding more than one method at a time) but they are separate tasks. Cheers, Ashley.
  38. In facts we aren't criticizing people adding features to the language, but the IMHO excessive expectations that the community seems to have about these features.
    That wasn't clear to me from your blog.
    I said I that my belly is really skeptical about new language features, but I don't publicy debate thoughts that are still at belly level. And before raising them up to the brain I'll wait for the existing proposals to be better defined (I see we're still at brainstorming level about syntaxes etc). What I'm sure is that, even though in the end I could perhaps appreciate some new features, I don't see them absolutely as a project saver. For instance, when I read this objection:
    As a result they have little time to think about what they are doing because they don't have time.
    I'm still more convinced that there are issues at the process level:
    1. There must be different roles and responsibilities in the team. Borderlines between roles may be somewhat fuzzy, but the leading role must be clearly defined. The project leader/architect must code too (in facts I code a lot, I usually don't believe in architects who don't code) but his main responsibility is to take decisions.
    2. If people can't find time to raise their head up from the code, especially the leader, this means that there has been a severe underestimation of the effort - which is a process failure.
    Reducing the time spent in coding won't fix anything if you don't fix the decisional process which lead to the underestimation. Knowing that with Java 7 people possibly save 30% time in coding, the next time the failed process will just plan 30% less effort and you're in the same situation. Is much like the car traffic problem. You have a congestioned highway with three lanes, and they build a fourth lane to address it. For some months it works, then people see that the highway is good again, more people go there and in a few time the highway is congestioned again. The real solution is to give people an alternate thing to cars. PS I hope my english level has not dramatically decreased this morning, as I don't feel really good...
  39. Re: It's NOT the code, stupid![ Go to top ]

    I'm still more convinced that there are issues at the process level:

    1. There must be different roles and responsibilities in the team. Borderlines between roles may be somewhat fuzzy, but the leading role must be clearly defined. The project leader/architect must code too (in facts I code a lot, I usually don't believe in architects who don't code) but his main responsibility is to take decisions.

    2. If people can't find time to raise their head up from the code, especially the leader, this means that there has been a severe underestimation of the effort - which is a process failure.

    Reducing the time spent in coding won't fix anything if you don't fix the decisional process which lead to the underestimation. Knowing that with Java 7 people possibly save 30% time in coding, the next time the failed process will just plan 30% less effort and you're in the same situation.

    Is much like the car traffic problem. You have a congestioned highway with three lanes, and they build a fourth lane to address it. For some months it works, then people see that the highway is good again, more people go there and in a few time the highway is congestioned again. The real solution is to give people an alternate thing to cars.
    OK now we are on the same page. What I see in most places is that a deadline is set and then the estimate is made to fit that deadline. I guess that's really a process problem but it's outside of the technical aspect of system development entirely. Having features that make development faster really help in this situation. The other thing I've seen is that when people sit down and talk about what they are going to do, they don't think about what tools they are going to use. It's already assumed that Java or COBOL or whatever will be used. In addition, the approach is also assumed (e.g. one JavaBean per table.) Most of the time these assumptions are made because of the prevailing wisdom of the day. Introducing closures, I think would legitimize certain approaches and make them more palatable. If I have this great approach but it means doing things that seem weird to people, they tend to not buy into it.
    PS I hope my english level has not dramatically decreased this morning, as I don't feel really good...
    'in fact' has no trailing 's'. Other than that your English is excellent. Don't take it as a slight. English is idiomatic and inconsistent.
  40. Re: It's NOT the code, stupid![ Go to top ]

    OK now we are on the same page. What I see in most places is that a deadline is set and then the estimate is made to fit that deadline. I guess that's really a process problem but it's outside of the technical aspect of system development entirely.
    In many organizations the purpose of process is primarily to make development more predictable, not faster or more efficient. If you collect enough data about projects you can start estimating them much more accurately, but collecting that data either slows projects down, requires significant infrastructure, or both.
  41. Re: It's NOT the code, stupid![ Go to top ]

    OK now we are on the same page. What I see in most places is that a deadline is set and then the estimate is made to fit that deadline. I guess that's really a process problem but it's outside of the technical aspect of system development entirely.


    In many organizations the purpose of process is primarily to make development more predictable, not faster or more efficient. If you collect enough data about projects you can start estimating them much more accurately, but collecting that data either slows projects down, requires significant infrastructure, or both.
    I worked in an organization where that was ostensibly the purpose but we always magically hit our estimates exactly. What would happen is about 7 months into the fiscal year, they would tell developers to stop reporting time for support because we had reached the allocation (a.k.a the estimate.) Then the next year they would use the reported time to create the new estimate, repeat. So the net result was a lot of effort put into reporting with no benefit. I always though that if upper-management really new what kinds of games were being played with the numbers they'd surely can the people doing this but the upper-level management was always changing (because of all the failed projects) and the people doing this always stayed in place. We would sit there in meetings and listen to the CIO talk about how great our numbers looked and think 'what a schmuck.' I was tempted to blow the whistle but I would surely be canned if upper-management didn't protect me and I wasn't sure they would being that I was a peon and all. Bringing this back to the discussion at hand, I think a process can be a good thing as long as you don't lose sight of what you are actually trying to accomplish. I've seen the process become an end in itself and become completely disconnected from reality. I find it to be an interesting parallel to some of the stuff in 'The Goal' by Eli Goldratt (who was, ironically enough, a software developer.)
  42. It's not the code alone ...[ Go to top ]

    ... but making the code easier to read helps. And not having to mentally filter all the getters/setters that are only boilerplate will help. And closures are really much easier to read and more powerful than their anonymous inner class counterparts.