Opinion: I think I'm done with thought leaders


News: Opinion: I think I'm done with thought leaders

  1. Opinion: I think I'm done with thought leaders (30 messages)

    Ever feel that the world that someone is talking about isn't you own? Rick Kitts and Mike Spille do. Rick talks about the "real world", of programming on a mainframe, the pain of tons of strangely encoded fixed records and complex business rules. Can the 80% of software developers find the land that is promised by thought leaders?

    What is the lag time between what a thought leader talks about at a conference, and how you can use it in the real world? The seems to depend on what they are talking about of course, but it can often be a fair time.

    There are some pragmatic thought leaders who deal with current issues and help you get around them, and others who haven't written a line of code for a long time, and talk about the future. We can still learn from both, but you can take your pick.

    Read Rick Kitts in I think I'm done with thought leaders.

    Read Mike Spille on the same subject, as well as the YAGNI principle (Ya Ain't Gonna Need it [optional: Dumb Ass]).

    Threaded Messages (30)

  2. You definitely live in a different world than I do. I've been programming in the "real world" for 16 years now. I've seen my share of legacy spagetti code, so I can at least relate to the frustration of having to make unnecessarily complicated code work. But by reading and absorbing ideas from the best thought leaders, I've managed to avoid repeating the same mistakes on new projects. I think a large percentage of developers work in the IT industry (fewer and fewer America based ones), and most of the projects are not rocket science. Use of good third party tools, standard patterns, standard methodologies, and sound software engineering principles go along way to creating clear/maintainable systems.
  3. I don't think the need for Good Design is ever going to go away. I see in my workplace every day programmers who bitch about the project's Checkstyle rules, rather than fix theeir code. Some of these I also disgreed with at the start but I just knuckled down and made my code complaint with the standard. But when you look at their code you see there is often a ton of bad design decisions taken that will have to be backed out and re-done to avoid stupid complexity later (for example; lists of products discerned in a switch statement where the list will very soon expand to over six times the current list). Maybe this will never get done and poor sod of a maintenance programmer will just have to deal with it.

    It is about human psychology more than anything, I think.

    But goddamn I am convinced that my code is going to be as well designed as I can make it. Sure that means all that 'patterns crap' is applied wherever applicable, I pay attention to what code quality checking tools tell me, I submit it for code reviews and listen to the comments, and the source style is in the corporate standard.

    Beyond that, what can you do? I take from the so-called 'experts' the things that I find useful and discard the rest.

    XP I have found useful for small green fields projects.
  4. Baby with the bathwater[ Go to top ]

    As someone who slogs through legacy or secondhand code everyday I can totally relate. Working as a consultant often gets me called in on projects that are nearly hopeless. When you are handling what amounts to steaming piles of dung everyday and read about the bright shiny surfaces of software perfection it's easy to get depressed and yet... Often times I find that it's the one little piece hidden in a "thought leader" throwaway comment that helps turn the steaming piles into something a little more antiseptic. Sure I work in a world rather removed from the bright and shiny, but one can always dream and I'm grateful for anything that makes it all a little more palatable.
  5. Bjarne disagrees as well[ Go to top ]

    Interstingly, Bjarne just said the following in an interview with Bill Venners:

    Bill Venners: How do we do that? How do we design for situations we can't imagine?

    Bjarne Stroustrup: You listen to a lot of people and then you aim for generality.

    Read the full interview.

  6. Great entry, Mike. I have taken offense at some of Rob Martin's statements as well, but I think the moral of your and Rick's comments is that once again, the truth lies somewhere halfway.

    No matter how disconnected from the real world thought leaders are, it's entirely up to you to pick from their thoughts whatever is relevant to your task.

    If you apply their recommendations blindly, you are as guilty as they are.

    "You aren't gonna need it" should be replaced with "Let's see if you might need it one day and then we'll make a decision", but it makes for a much less sensationalistic weblog entry, especially on Artima.
  7. Damn straight[ Go to top ]

    It's very very good to see that other people feel this way too.

    The problem I think is that many of these so called 'thought leaders' advocate their own particular simplistic solution because at some point, they happened to work on a simple project that was addressed perfectly by their drug of choice.

    It's easy from that to fall into the delusion that you've discovered some kind of holy grail, that it wasn't luck, the nature of the project, and the easy environment and sensible requirements that made your project succeed, that somehow it was your own genius in choosing to use TDD that resulted in the wonderful success your project had. That somehow, instead of being a cog in the process machine, you're the sole factor that brought about the success. All it takes is coupling this with previous delusions of grandeur and a good dose of zealotry and urge for public recognision for said 'thought leader' to start bombarding the world with his new 'discovery'.

    That of course leaves a whole swathe of poor saps who desperately want to believe that the holy grail has indeed been found, and try to shoehorn that one stop shop solution to their own situations. This, as the blogs mentioned realised, causes much discomfort all round as the poor saps realise that their problems just aren't as simple and childish and idealistic as the Fearless Leaders proclaimed.
  8. Damn straight[ Go to top ]

    It sounds trite, but maybe what we need is more Fearful Leaders, and fewer Fearless ones.

  9. Damn straight[ Go to top ]

    I think a little humility would help some leaders as well.
  10. a good dose of REALITY[ Go to top ]

    And REALITY may be purchased here at the special introductory price of $19.95 per kilogram;

  11. humility[ Go to top ]

    I think a little humility would help some leaders as well.

    I would say that true humility is the ultimate sign of confidence in an engineer, and the ultimate sign of respectfulness in a leader.


    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  12. Why can't we have a competition about the most useless IT related advice ever?

    I hereby propose my candidate,

    Object-Oriented Systems Analysis: Modeling the World in Data
    by Sally Shlaer and Stephen J. Mellor March,1988

    "how to learn Object-Oriented Analysis and Recursive Development (OOA/RD) is a mature, rigorous object-oriented system development method. a must read"

    That of course on the condition that Cameron does not enter the competition which would be unfair!

    Rolf Tollerud
  13. Damn straight[ Go to top ]

    It sounds trite, but maybe what we need is more Fearful Leaders, and fewer Fearless ones.

    I am not sure that is the answer.

    What we need are more leaders who are actually in depth walking through code swamps that are finding ways to adapt these technologies to our problems.

    It's all find and dandy to have solutions to work on a new project, but unless you find a way to take a lesson and adapt it to what you're doing...who cares.

    Also, once you get that lesson to work in a prototype session, you need to be able to:

    - Convince your co-workers, technical leads, etc., that this change will actually produce an overall benefit in terms of whatever your corporate culture is. Show that it will make your technical life easier. If you've been drilled about software quality, this had better be able to produce a higher quality code.

    - Convince management that changing your methodology will actually reduce costs. Be it upfront, or during the maintenance cycle. Convince them that it will actually help meet your goals. That is, if your culture is more about pushing code out the door quicker and to the customer, rather than perfect quality, then unless your solution can do that, you might as well forget it. If you're getting hammered on maintenance time cycles, then you had better come up with something that can reduce the time cycle.

    So maybe what we need are not more technical software leader guru types. Maybe what is really needed are more technical software leader types who drop the software stuff and move into business roles. That way you get business people who are more concerned about a quality product, and less concerned about it taking an extra 20% of time.

    All the tricks in the world will not save you from lack of business buy-in due to added up front costs.
  14. Gosh darn straight[ Go to top ]

    It sounds trite, but maybe what we need is more Fearful Leaders, and fewer >> Fearless ones.

    It seems that with the maturation of Java, OOA/D, and everyone getting past a few iterations with their stack of choice, what was once considered right-on and timeless is now abstract and dated. I blame this on stable frameworks, meaningful design patterns, and free tools that implement proven, even thoughtful, techniques. We have to give credit where it is due for past thoughts. Maybe it is time for "do" leaders now.

    Other thoughts I blame:

    I blame EJB and J2EE pattern books for helping me design with confidence.

    I blame frameworks and implementations like Struts for following those patterns.

    I blame Rod Johnson for making me rethink that confidence.

    I blame Kent Beck for managing scope and code that gets checked in with test cases.

    I blame Martin Fowler for the word POJO.

    I blame sourceforge for providing a petrie dish to realize many deep thoughts.

    I blame Craig Larman for making it too easy to understand.

    I blame Booch for his clouds (any selling Rose as a viable tool).

    I blame the three amigos, the gang of four, and n-tiers.

    I blame IBM for thought enabling and opensourcing Eclipse, its plugins, CVS and ANT integration.

    I blame JUnit but I make no assertions.

    I blame theserverside.com for questioning these thoughts. theserverside.net seems to not question central committee thought and so I place no blame.

  15. Individuals[ Go to top ]

    I have come to the conclusion that (at least in my "world") lots depened on the few enlightened, mature, motivated, experiences and educated individuals.

    You have a project with the guy or two like this, and all your "though leaders'" practicies fall into the right place. If the right mindset is absent
    you can try to apply any best practice, process, methodology - it all ends in vain.

    I would like to know though what these thought leaders do for living beside speaking on the conferences and writing books. How did they help projects in the real life, what are their success stories. Not that I doubt anyone, but I just have not seen much of it advertised. Contrary, I have seen some amazing software successes in terms of the user satisfaction, const-benefit and quality done in a very traditional or unexciting manner.

    I asked one of my friends who works for a company that kicks butt with their really good B2B solutions what kind of process or methodology they follow.
    "Nothing special" He said "Process is a just regular release based waterfall,
    use Java, RDBMS, XML. No fancy architectures". They do have some really smart people working on their products, and their CEO has a crisp clear business and tecnological vision. Maybe we are all seeing too much, and expecting too much from the regular application or software development.

    Day, by day I am getting to recognize KISS (Keep It Simple, Stupid) as an essential software development approach. Strong, mature professionals can make it work right.
  16. Individuals[ Go to top ]

    The problem is that many Thought Leaders aren't really leaders at all, they're just people out to make big consulting/seminar bucks with faddish methodologies.

    For the case in hand, I went back and looked at the example Martin used - an opens source system called FitNesse he and some others developed. The source code is like a hand book for worst practices. Many methods are tagged "throws Exception". Many times a literal "throw new Exception (...)" is used. There are _zero_ code comments. No javadoc comments to speak of. The file persistence thing that his team was so worried would bog down development and cause all sorts of problems? 325 lines of boilerplate file handling code - again, full of "throws Exception" and no comments at all.

    Here we have a Thought Leader who charges big bucks for consulting and seminars, plugs his company Object Mentors regularly, and has for decades strived to place himself as an expert of OO methodology. Problem is, his code is simplistic almost to the point of childlessness, he uses easy outs like "throws Exception" everywhere, he apparently thinks comments get in the way of being Agile.

    Typical - someone telling us how to write Enterprise code who can't write a simple little code base themselves. Someone who extrapolates a rather awful toy implementation and thinks the little tricks that work there apply to true enterprise systems.

  17. A good example[ Go to top ]

    I submit Doug Lea as a noteworthy thought leader that fits your bill. His work with JSR 166, which has come after a years of contributing the KISS principle for Java concurrency among many other things, is helping to refine the JCP (http://www.jcp.org/en/resources/guide/166-casestudy).

    Any votes for Martin Fowler?
  18. I wonder how the software industry have been like without people willing to share theitr ideas?
    It is impossible to know beforehand what are good and bad ideas anf thoughts, and bothe must be tried in the real world and in a lot of projects before they prove their right for existense.

    I try to keep up to date with ideas from several sources (thought leaders) and combine them in a appropriate way for the current project. It would be silly to think there is a universal solution for all problem domains. Common sense must be applied to all projects, and applying whatever you heard of recently may not be appropriate for your current project.

    So far the only thought leaders who has ideas (or just a funny/interesting packaging of commmon sense), that applies to most projects, is The Pragmatic Programmers. Use their ideas as a basis, and take it from there. Do not try to introduce any silver bullets and revolutionary ideas. Projects who do that fails nearly all the time.

    I have a good feeling about XP and Agile methods, but RUP/Waterfall out of the box does fit not the kind of projects I have ever worked in. Often many organizations who buys these process frameworks try to use them out of the box, with a sadly result.

    Dag Blakstad
  19. Come on[ Go to top ]

    Hi all,

    I think that smart people collect the knowledge and experience from any source, including books by thought leaders and by newbie writers. But they don't apply blindfolded what they have learned, they think first. There are many cases when good advice is used in a wrong way.

    One person's experience is never enough for the whole world. Those who are called "thought leaders" here try to generalize their experience in an effort to address more problems than they have encountered. Sometimes this works, sometimes not. But it is your responsibility as a software developer to decide when to use an advice and when to use only your head. You can't blame anyone for not solving your problems.

    And do not turn down reading books just because they don't apply to your work in their entirety. And also I am personally thankful to those developers who find time and strength to work on writing. (Coding is more interesting, eh? :)

  20. I have to agree with the sentiments expressed here. I can think of a few good books I've read: "The Pragmatic Programmer", "Design Patterns", "Refactoring" - books that have helped me hone my craft as a programmer. But a lot of stuff I've read has just muddied the waters for me.

    Much guru-talk is heavily anecdote driven. The gurus do something on a small number of projects and draw general conclusions from them. And those of us working on projects that don't fit the mould feel like we're not "getting it" until we realise that the gurus don't get us!

    I can understand the excitement of discovery. You come up with a new object-relational mapping tool that does everything you want and you can't wait to tell everyone that that is the way to go. Someone reads your advice and wastes a lot of time trying to use the tool with a database where you update the data with stored procedures and read it through views. And, of course, another thought leader said you shouldn't have set up your database like that in the first place and the spiral of denial moves ever onward. And poor Joe Programmer is left to their own devices to deal with what is actually a common situation.

    Here's my hint for how to deal with the "thought leaders". Whenever you read their advice ask yourself what they were doing when they found this wisdom. Look for their examples, read between the lines, try to estimate how many systems they tried their approach with. If their "test cases" don't cover the kinds of systems you write, take their advice with a pinch of salt.

  21. I agree, the Programtic Programmer is about methods not a methodology. The same distinction between an idea and an ideology.

    And the words 'I wouldn't have done it like that' help no-one ;-)

    Neil Ellis
    New Convert to Opinionated Programming.
  22. OldSKool[ Go to top ]

    In 'The Old Days' (TM) people learnt from reading other peoples source code, code to programs that was generally considered of a very high quality.

    Somehow, probably due to the complexity of J2EE and its spawn of bastard children ( O/R mapping, Patterns, IOC, et al ) we are now learning by reading peoples words. Which of course, unlike programs have no independent measure of quality.

    When I was at uni I read Tannenbaums Minix book ( OSD&I ), half of it was source, the other half described the source and the general concepts used.

    Maybe it's a maturity thing, with the rate of change increasing, but most trendy books published today don't remind me of the hefty, infomation dense text books of uni.
  23. OldSKool[ Go to top ]

    In 'The Old Days' (TM) people learnt from reading other peoples source code, code to programs that was generally considered of a very high quality.

    > Somehow, probably due to the complexity of J2EE and its spawn of bastard children ( O/R mapping, Patterns, IOC, et al ) we are now learning by reading peoples words. Which of course, unlike programs have no independent measure of quality.

    I would disagree at calling OR mapping and patterns "bastard children" of J2EE, since those existed before J2EE. Ok, maybe J2EE pushed these further, but I would see that as a good thing instead.

    > When I was at uni I read Tannenbaums Minix book ( OSD&I ), half of it was source, the other half described the source and the general concepts used.
    > Maybe it's a maturity thing, with the rate of change increasing, but most trendy books published today don't remind me of the hefty, infomation dense text books of uni.

    I would say that it could be because of the level of "abstractness" is increasing. We are already seeing tools which goes from UML diagrams to programs directly, where code is being relegated as a second-class citizen. I don't know who will win the war between Design and Code, I just want to be safe and confortable knowing both, whatever comes out of this. But indeed, the level of complexity is increasing a lot, so much that we don't have enough time to study tons of coding before we understand how things work. We have to learn things by new means, and in more abstract ways. It can be harder this way for some (most?) people, and maybe that's why some kinds of projects are bound to fail at a higher rate.

    Henrique Steckelberg
  24. Are we missing the point?[ Go to top ]

    The bl ogI read didn't seem to have anything to do with programming, design, architecture, or anything like that. The conditions that the author has in italics are the result of ancient business rules that got carried forward (not too far forward with terms like "mainframe" in the body). This is the old "paving the cowpath" problem. I don't see where devaluing good approaches has anything to do with trying to use modern tools and techniques to perpetuate and render ancient work-around processes.

    There's a big difference between the way things work and the way we've made them work. Too often, we confuse the latter with the true business rules. This is particularly the case with legacy applications. That is, the technical constraints of twenty years ago and the workarounds that those constraints gave birth to became the law.

    I always remember early in my career that a business partner said, "we have a rule that a Customer can only have two addresses." I remarked that there are some cases where the Customer can have a Home Address, a Business Address, and Second Home Address. They business partner said, "well that's all we can have - two." As it turned out, the source of that rule was an obvious technical constraint - that being an eighty column "A" card that could only hold seventy-two spots. They simply didn't have relational systems, collection classes, and the benefit of decades of trying to get it right.

    So, folks, if you're given an opportunity to do a "green field" branny new system, then you have the opportunity to benefit from the decades of collected wisdom. If you're stuck porting a legacy system, then you better take those, ahem, business rules with a grain of salt or take the effort to try to find out "how the business works and not how they made it work" and _DESIGN_ accordingly.

  25. Are we missing the point?[ Go to top ]

    If I read Rick's article right, he's not talking about porting a legacy system. He's talking about interfacing to a legacy system. Sure, if you're rewriting an application then that's the perfect opportunity to re-examine the business rules and say, "Is there a better way of doing this?". In your example, you could improve the system by adding the capability to hold an arbitrary number of addresses. But if you're interfacing to that old database system, you are stuck with the fact that you can only have two addresses because that's a fact of the application and you cannot change that fact no matter how much you want to. The only thing you can do is code round it and live with it. That's the reality that most programmers come up against in the real world because it's quite unusual to get a chance to start from a completely blank piece of paper. You almost always have to deal with someone else's baggage, and after you're gone, someone else will have to deal with yours.
  26. Have you ever liked an existing code base?

    You know, you start on a two year old project and look through their pictures, docn (OK, you don't), you look at their code, their queues, their value objects and EJB's, their deployment descriptors and Struts 1.0. And after that you say, hey thats cool, lets not change it, they made all the right choices.

    I'd say no in every case. Instead you say 'this is a pile of, err, rubbish' and try to get the bugdet to rewrite it or do something completely different. Hey lets use Java Server Faces in an IOC container with aspects, DTO's and Hybernate (or whatever).

    And two years down the line you move on and someone else takes on your brilliant software and guess what they say?

    Now move into the business of methodologies. Hey Booch was brilliant, it had it all! Actually, no, its UML1.0! Err, no, Agile XP is the way forward. Except it's really UML2.0, meanwhile Prince 2 is best... etc.

    My personal principles on all things IT are:
    a) It gets used (this is the most important criteria)
    b) It works (implies scales, and is robust **as required**)
    c) It logs why it did what it did. And there is someway to work out how to recover from an error report.

    And you make that fit into whatever the current 'best of breed, decoupled, heuristically led, small container, bloatware, picture oriented, refactoring factory of factory sessions' place you work in.

    But reading books can never hurt - train forever.

  27. Well said[ Go to top ]

    You know that made me think, I really only have a handful of rules todo with coding and these are all linked to having to deal with day to day stuff, off the top of my head the list would include:

    * Let no exception be uncaught
    * Let no exception be unlogged
    * Let almost every exception be logged and rethrown unless you're going to actually do something useful with it.
    * Add more logging.
    * Add a bit more logging.
    * Don't put anything into one of those rather nice configuration/resource-bundled/xml-configured/database-driven/non-hardcoded/totally-flexible files if you're never going to change it, ever bloody ever!:

     int pi= MyServicesLocator.getMyServices().getConfigService().getComponent("Dave").lookupInt("PI");

     I mean who the heck changes the value of PI anyway (sigh).

    * Don't write code for yourself, write it for:

         * The customer, they're paying your wages - so make sure it does what they need.
         * Your colleague who will fix it while you are on holiday in Barbados; or if you live in Barbados then your colleague who will fix it while you're on holiday in London.
         * The guy who will take over your job when you leave.
         * The person who has to deploy it.
         * The people who will have to test it.
         * The people who will have to support it once it's in production.

    * If you have to put in comments explaining what your code does then your code probably needs rewriting. Why call a variable a and then write a comment

                        // a is the height of the apple
                        a= 10.5;
         why not
                       appleHeight= 10.5;

    * Log messages, variable names, method names, parameters, classes are all comments and should be used as such. This way the commenting becomes a description of the method from the callers perspective and you rarely if ever have to explain the code yourself.

    * Everyone else's code is rubbish mine is the best :-)

    * The only people who really care about writing good code, write it already :-) :-)
  28. Well said[ Go to top ]

    Wow, Neil, that's quite a tour de force. Quite well said.

    I take issue with the comments bit somewhat, though. I agree that commenting on minute code bits is useless - my own favorite is:

       // Set foo to 1
       foo = 1;

    However, I do believe strongly in higher-level code comments - comments that indicate information at a higher level than just your lines of code or classes. For example - how to use a class, its lifecycle, gotchas, constraints, and especially the gestalt of complex algorithms. Sometimes a simple comment like the following goes a _long_ way towards understanding:

        * Note: The complex locking here is a specific performance improvement
        * to a prolem we found profiling. We're locking specific pipe line stages
        * here now rather than the one big lock and/or a queue consumer to avoid
        * prolems we've had with too many thread context switches. Understand the
        * pipeline stages and the flow and you'll understand the locking.

    Developers often forget that after-the fact it's sometimes extremely difficult to divine the reason and intent behind more complex blocks of code. I always try to follow KISS, but sometimes complexity is unavoidable. In those instances, comment the complexity and _why_ it's complex.

  29. Well said[ Go to top ]

    Mike McConnell's book Code Complete has an excellent chapter on comments. His argument is basically the same as yours: comments should not explain what the code does, they should explain why it does it. It's getting a bit out of date now but it's still one of the best books on general programming I've ever read, along with The Pragmatic Programmer. Every now and again I get exasperated with some of the people I work with and wave one or other of the books under their noses shouting, "Read this, you morons!"

    The one thing I'd say is that comments aren't only for complex blocks of code. In your example, the locking could be very simple, consisting of maybe just one line of code. Anyone reading it can easily see what it's doing. What they can't see is why you need to lock at this particular point in time. In your example, you'd still need the comment to explain the fact that it's a specific performance enhancement, etc. etc. so that the next guy looking at the code knows he can't move the locking back "where it belongs".

    The key is what Neil said: always think about what your code is going to look like to the person who comes along after you and has to maintain it.
  30. Well said[ Go to top ]

    This "commenting style" suggestions are just the same as when you write a book or a user's manual: put yourself on the user's place, and try to imagine what the end-user would think of what is being written. Do it all the time, and you will understand when, where and how to write things in a proper way. We just have to apply this to code commenting, and imagine: "what would someone who is seeing this code for the first time think of what is (or isn't!) written here".

    Henrique Steckelberg
  31. Well said[ Go to top ]

    Can't argue with that. I apologise for my generalization (rant mode was switched on) and I admit I can be quite lax on my own commenting. What you've described is ideal; it is you explaining to the reader that which is not in the code itself. This and API comments which are explaining the contract with the client code - I agree is what we should aim for.