Discussions

News: 'He's Just a Techie': Image and Impact of the Software Developer

  1. In this article, Peter Pilgrim describes the perceived image of the software developer as seen on a recent Microsoft TV commercial. He talks about the gulf between developers and the non-technical business folks, the lack of standard industry accreditation in our field, and believes that the old 'techie' stereotypes need to be shed in order for developers to get the respect they deserve.

    Read 'He's Just a Techie' - Image and and Impact of the Software Developer

    Threaded Messages (62)

  2. Generalizations?[ Go to top ]

    In 'Mythical man-month' there was a point that good software developers are sometimes 10x more productive than bad ones. And this is still true. Personally, I've seen a lot of those who did spend few weeks to accomplish something that would take few days of more quick-minded guy.

    I would say there's no such thing as 'average' software developers. I saw a few true stars who usually deliver 90+% of project value, and there are losers and wannabies who keep their jobs just because management values their 'unique' knowledge of 5-years-old code (who no one else would want to maintain). Or just because productive developers usually are becoming, well, expensive, and usually work for fair consulting rate rather than for modest salary. Or maybe even because for productive developers even in tough economy there are still a lot of job opportunities.

    So to me, any generalizations about 'software developer profession' are senseless. At least some classification is needed.
  3. Software does not exist in a vacuum. The purpose of software is to solve problems, and 9 times out of 10, those problems are business problems.

    This means that every software company (that wants to make money) has to find a way to bridge the gap between the people who make software, and business people who couldn't care less about it and just want it to work.

    IBM does this by hiring techies who can put on a suit and tie and relate to business people. This works well, but those kinds of techies are few and far between, and they cost a lot of money.

    Apple follows the IBM model, except that thier business is more focused on artistic/creative types, and so they get developers that relate to those kinds of customers and understand those customers.

    Microsoft solves this problem in a completely different way. They hire the smartest techies they can find and lock them in a back room. Then they hire slick, business-savvy salespeople to go out and interface with the customers. The salespeople then give requirements to the techies, who build the software.

    Sun, unfortunately, only has one half of the equation. They have an excellent technical staff, but they have no one (well, almost no one) who can talk to business people. This is why they're losing money hand over fist; They can't relate to thier customers.

    None of these methods are right or wrong in the context of a sucessful business (except for Sun, who needs to clean up thier act). The IBM and Apple models put more power in the hands of the technical staff, while the Microsoft model puts more power in the hands of the sales staff. If you were to look purely at the balance sheets of these companies, you would probably conclude that the Microsoft method is superior. However, If you looks at the quality of product that these companies put out, you would probably reach the opposite conclusion, so in the end, it may be a wash.
  4. Business savvy roles[ Go to top ]

    I cannot agree more with 'Building Bridges (Not the design pattern)'.

    Is it software developer's responsibility to calculate ROI and bridge business objectives and technical architecture? No. Software architect should be the one that bridges business and technology. However, it is too common that the software architect in the project is just a 'application architect' who does more on technical details than build bridges. They don't usually perform the role of building bridges:
    * Do they use a method (such as CBAM) to calculat ROI?
    * Do they use a method (such as ATAM) to relate quality requirements and techinical architecture?
    * Do they actively drive the requirements?
    * Do they communicate to the software developers on business drivers?
    In many projects, there is no process to bridge business and technology.

    Those 'the most productive' Software developers in a project often only focus on technical side, totally rely on analysts to do the requirements, and cannot prioritize quality attributes to his work. This is not good. Remember 'there is no killer application, only killer user experience'.
  5. The magical 10x Productivity.[ Go to top ]

    Those 'the most productive' Software developers in a project often only focus on technical side, totally rely on analysts to do the requirements, and cannot prioritize quality attributes to his work. This is not good. Remember 'there is no killer application, only killer user experience'.


    In my opinion, you want your programmers to focus only on the technical side, more specifically, just on coding. They should only have to worry about requirements or design issues enough to understand them. The job of the Project Leader/Software Architect should be to solve all of these problems for the programmers so that they can stay in "The Zone"[1]. This is where that magical state of 10x productivity comes from...and not everyone can do it. I'd say only about 15% of the programmers out there are still enough to maintain the state of hyper-productivity for prolonged periods. But even those top 15% can only do it if they don't have to stop coding to have yet another requirements meeting with a customer, or spend a day or two working out the design for a new subsystem.

    This is not to say that architects should not write code and programmers should not design, it's just that everyone on a project needs to stay focused on exactly what they bring to the team and not get too distracted. Otherwise your project will go nowhere fast.

    [1] http://www.joelonsoftware.com/articles/fog0000000068.html
  6. The magical 10x Productivity.[ Go to top ]

    I'd say only about 15% of the programmers out there are still enough to maintain the state of hyper-productivity for prolonged periods. But even those top 15% can only do it if they don't have to stop coding to have yet another requirements meeting with a customer, or spend a day or two working out the design for a new subsystem.

    >

    Reading the boards, I'm finding the constant references to the 'top 10%' of the development community. I'm certainly not implying, Ben, that you have said you are in this category (as you have not said that), I just see this reference so often. I'd speculate that most of the posters bringing this up assume they, in fact, are in this elite group.

    The truth is that this might have some merit to it but I'd say experience and motiviation vs. natural ability makes someone a superior developer, usually. There are some who just don't and will never get it and they usually don't stick with it long term. Not to mention that developing software has many different facets, beyond coding - and I've seen examples where IT-types are good at some things/bad at others.

    Sorry, off topic a bit. I just find this references amusing.

    Mike
  7. The magical 10x Productivity.[ Go to top ]

    I often categorize developers in three groups: Strong individual contributors, team contributors and dead weight.

    If your team is only five people, you probably want as many strong individual contributors as you can get, because these are the developers that can self-train, design, code, build, fix, etc. They wear all the hats, and excel at almost everything they do, because they intuitively understand the domain -- they just "get it." And when you have a small team, it helps if everyone can wear just about any hat.

    Big groups are much more difficult to make into effective programming teams. In fact, strong individual contributors can even be problematic to manage and keep happy in a large team. However, if you can get from the "strong individual contributors" a good architecture and clearly defined patterns (in the conceptual sense, not necessarily the coding sense) you have a good chance to get the "team contributors" to effectively fill out the bulk of the solution.

    So team contributors might not be able to architect, but given an existing architecture, a task and a little bit of guidance, they can build 90% of the application.

    The biggest problem is that a certain percentage of developers falls into the third category, which I would describe anecdotally as: "Gee, we would have been better off if we never put [insert name here] on the project. Not only has he/she not properly finished his/her tasks, but it's going to take us additional work just to reverse out the damage that he/she has caused."

    So regarding the "value scale," you do have developers who are 10x as good as other developers, but it's actually pretty easy to accept that some people can contribute much more than others -- as long as they are all in the "positive column." The truly frustrating part is having to deal with the ones that end up on the wrong side of the zero score.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  8. Over and over again, we hear that some programmers are 10Xs more productive than others. This is tired truism that does not make much sense for an activity that is so collaborative.

    I have seen cowbody coders crank out extreme amount of code in just a few weeks and then I've seen dozens of people spend years struggling to make that same code work properly.

    Judging productivity is tricky business. Some people may not write that much code, but they make the rest of the team more productive by innovating or teaching. Others write a lot really bad code that diminishes the productivity of everyone else. There is no accurate way of measuring productivity, which is why software is as much an art as it is a science.
  9. I disagree with you that a programmer codes and others worry about the other details. Granted, a great deal of my experience has been in smaller shops where there is not much a delineation between coder/architect/analyst/etc. In those cases, you cannot afford to have someone who only codes or someone else only interfaces with clients and prepares requirements. And yes, I have been in the zone for weeks at a time and it is a marvelous thing when the human body reaches that level of cohesion and works towards a set goal. BUt I digress.

    I am not working in a larger corporate environment where I could, if I so chose, bury myself in a tide of technology and write code all day. However, what I took from working in smaller shops is absolute surety that I cannot create meaningful without understanding why I am creating it. How many times have you started a new project or a new job and were told to build X by a project owner? So you spend your time and Build X, show it to them, and are told that's not what they really wanted. You can point to every requirements document in the world, but if that's not what they want, then you're going to end up building Y. And if that's not it the Z, X1, Y1, etc. etc. etc. So, we have been 10X productive because we didn't allow ourselves to be bother by meetings, but we took one-tenth the amount of time to build something that was still 100% wrong.

    The best defense against this is communication and understanding. As programmers, we have got to understand the motiviating factors behind our companies and how what we build fits into those factors.

    Example: A stakeholder asks for a lampshade to cover his lamp. Now, you can rush off and build his lampshade, return with it, and find that the original problem all along was that it was too bright in the room, so what you really needed all along was a light switch to turn off not only the lamp next the stakeholder by the ceiling light as well. Dumb example, I know.

    However, when you are requested to do a project, learn why you are doing it. It could be that the requested solution is affecting only the symptoms of the project rather than the cause. More importantly, there could be a better way to solve problem that is different than the proposed solution. Our stakeholder may have sensativity to light and need sunglasses, not something to cover the bulb in his lamp. But you're not going to know that unless you understand the whole problem.

    I find it odd that in a industry where metadata has become so important, so many people want to ignore the metadata of their organizations.

    So, how do we increase our understanding? Communication. We have to communicate with our organization's leadership to understand our company's values. Then we need to communicate with our clients and our analysts to understand the driving force behind requested changes. Not only that, but as IT, we have a certain way of doing things and a certain set of jargon. It's been my experience that if an analyst or stakeholder truly wants to be effective, they will make every attempt to work with IT. You can't make a salesperson stop thinking like a salesperson, but you can educate him to what data is required before they approach IT.

    Sadly, this means that as programmers, we may have to talk to customers and fellow employees. Unfortunately, if we're going to be the core of modern business, we need to start acting like it. If we're the center of the business world and everyone relies on us, we need to be reliable. We need to be able to communicate our needs effectively while simultaneously understand the needs of those we serve.
  10. Re: 10x Nothing is Still Nothing[ Go to top ]

    I disagree with you that a programmer codes and others worry about the other details. Granted, a great deal of my experience has been in smaller shops where there is not much a delineation between coder/architect/analyst/etc. In those cases, you cannot afford to have someone who only codes or someone else only interfaces with clients and prepares requirements.


    SNIP!

    Well, when I talk about programmer/architect tasks, I'm talking about roles, not people. Just as you can have more than one person filling a role (4 programmers on a project), you can have a person filling more than one role (1 person on a project who is the sole developer and architect).

    And I agree with your point that developers (indeed, IT people in general) have to do a much better job of communicating than they have done in the past. The problem is that developers can't spend all day in meetings talking to people...they actually have to get some work done. That's why it's the architect's job to manage that communcation process so that it's as efficent as it can be. Architects/managers have to track down relevant information and find useful contacts. Then they pass that along to the developers so they can get a good idea of the scope of the project without having to spend the whole day in meetings.
  11. Unfortunately most of the people I know with the word 'Architect' in their title are usually a waste of office space. I couldn't help but remember the BileBlog entry: The senior architect syndrome

    Although I do agree that SOMEONE needs to do these activities, otherwise you just waste your money having developers who can't run at full speed.

    Rob
  12. Unfortunately most of the people I know with the word 'Architect' in their title are usually a waste of office space. I couldn't help but remember the BileBlog entry: The senior architect syndrome

    >
    > Although I do agree that SOMEONE needs to do these activities, otherwise you just waste your money having developers who can't run at full speed.
    >
    > Rob

    Couldn't agree more. I've seen it in every Fortune 100 company I worked (consultant and employee) in the US. These guys make tons of money and provide little real value. They are experts at office politics.
    No wonder IT is getting outsourced.
  13. Apples to apples[ Go to top ]

    No no, I didn't mean comparing extreme code-focused developers with more business-aware ones.

    I'm just trying to say - in very same environment, with very same set of requirement - there are software developers who can do something in two days and there are other guys (maybe sitting in the same room) who are also called 'software developers' and they will require two weeks to accomplish same task, with same quality level. And this is not the question of education or even experience. It seems like it's their 'size of 1st level cache', 'brain CPU clock' and 'memory access speed' that matters.
  14. Apples to apples[ Go to top ]

    'size of 1st level cache', 'brain CPU clock' and 'memory access speed'


    Hilarious and true!
  15. Building Bridges (Not the design pattern)[ Go to top ]

    Software does not exist in a vacuum. The purpose of software is to solve problems, and 9 times out of 10, those problems are business problems.

    >
    > This means that every software company (that wants to make money) has to find a way to bridge the gap between the people who make software, and business people who couldn't care less about it and just want it to work.
    >
    > IBM does this by hiring techies who can put on a suit and tie and relate to business people. This works well, but those kinds of techies are few and far between, and they cost a lot of money.
    >
    > Apple follows the IBM model, except that thier business is more focused on artistic/creative types, and so they get developers that relate to those kinds of customers and understand those customers.
    >
    > Microsoft solves this problem in a completely different way. They hire the smartest techies they can find and lock them in a back room. Then they hire slick, business-savvy salespeople to go out and interface with the customers. The salespeople then give requirements to the techies, who build the software.
    >
    > Sun, unfortunately, only has one half of the equation. They have an excellent technical staff, but they have no one (well, almost no one) who can talk to business people. This is why they're losing money hand over fist; They can't relate to thier customers.
    >
    > None of these methods are right or wrong in the context of a sucessful business (except for Sun, who needs to clean up thier act). The IBM and Apple models put more power in the hands of the technical staff, while the Microsoft model puts more power in the hands of the sales staff. If you were to look purely at the balance sheets of these companies, you would probably conclude that the Microsoft method is superior. However, If you looks at the quality of product that these companies put out, you would probably reach the opposite conclusion, so in the end, it may be a wash.

    There is a fourth and fifth way.

    Fourth, being an open source project where an IT organization actually has the power to implement their own requirements and push it back on the community to maintain. Before I worked for JBossGroup, I was in this position and I loved it. Finally empowered to fix or enhance the product I was using to develop. Dr. Christoph Jung, our Web Services lead, is another example of this in action as he works for a commercial company with vested interests in this working.

    Fifth of course, is the JBoss Group model. We are all minimum 50% development, and I must say that doing support, training, and consulting gives you a unique perspective on the needs of your user base. I've worked for a few companies in my career (and talked to others) and I must say that many companies fall into the Sun catagory, great ivory-tower technies and solid technology that don't meet the needs of their customers. When you teach something you have developed, you usually can instantly find out if your code is ridiculously easy or hard to use. Doing consulting and support you find out what customers truly care about.

    Another cool thing about this fifth model, is that you end up being more productive as an organization because you focus on what customers want, instead of writing code that they might need. Anybody know of any other organizations that do this sort of thing of combining training, consulting, and/or support with development?

    Bill
  16. Generalizations?[ Go to top ]

    And I was thinking that I am alone in the universe with the same observations :)

    The article describes exact situation in our company. Probably because each company has its own corporate culture and management style it's impossible to cover all situations, but I think the article did capture a typical one.

    <quote>
    and there are losers and wannabies who keep their jobs just because management values their 'unique' knowledge of 5-years-old code (who no one else would want to maintain).
    </quote>

    I've seen it myself. A Microsoft ASP (Active Server Pages)-based application consisting of more than 900 ASP pages. No server side code. No single line of comment. And it has been maintained for 6 years by one of the original developers.

    A recipe how to create a job for life: write undocumented, not maintainable applications - the company will treat you as the most valuable employee because no one else will want (or be able) to deal work them. Are you laughing? Unfortunately, it’s sad reality.

    Yes, the respect has to be deserved through hard work. But due to popularity of the resume-driven development, a number of software projects keep coming out as needlessly complex and badly designed. By lowering the bar of professionalism we can worsen the perception of the J2EE platform among non-technical shareholders.


    [Sorry, couldn't resist.]

    Valeri
  17. Nitin is second guessing society, especially corporate Amerika. If he wants more respect, then he should sieze it. If he can't seize it, then he doesn't deserve it. Seriously, why does anyone deserve more respect than the janitor? During the dot-com boom we were speculatively creating unprofitable applications with wreckless abandon. How much respect would a civil engineer deserve if he did the same with bridges?

    I grant Nitin that it is ironic how the dude who writes firmware for a pace maker legally doesn't need a high school diploma, but the nurse's empty bottle of nail polish was designed by an engineer who needed a license. As a free market fanatic, I prefer the lack of entry barrier that we developers enjoy. My brother has an international business degree, and he's a higher paid software architect than I at a firm listed on NYSE. My dad rose to one level beneath vice president of AT&T without a college degree. He started there as an assembly language hacker. So don't tell me about how developers are overlooked. Entry barriers are for anti-competitive wussies. Does Nitin appreciate that a developer is the star of this TV commercial? A housewife has to be shown mopping the floor to star in a TV commercial.
  18. 'He's Just a Techie'[ Go to top ]

    Nitin did not write this.
  19. Hi Brian,

    Just for the record, the opinions expressed in the article are solely those of Mr. Pilgrim (the author of the article), and don't necessarily reflect mine or those of the TSS staff.

    I'm presuming that you intended to address Peter in your message? :)

    Best Regards,
    Nitin
  20. How do you compete in a software development team. Competition can make people play politics which is against the team-spirit and meritocracy. The author brings up a good point. How do you measure a person's capability in software development?
    Is it based on how quickly you get done ?
    Is it based on how well you architect, design and code? (if yes how do you measure this)
    Is it based on how well you perform in interview on a given day?
    You may succeed in short-term and fail in long-term.
  21. What's the problem with certifications?[ Go to top ]

    Wouldn't you get scared if you knew that your car's ABS system was the first program that its programmer ever wrote?

    Would you like it if airplane software was written without any good quality assurance and without any testing, because of time pressure?

    Why do we have such strict regulations for the airplane industry, anyway, because we believe in 'the self-regulating free market'? Or maybe because we
    don't want to wait for the 'the free market' to become self-regulating only after some real disasters have happened.

    Ok, how about a bridge, would you drive over it if it were built by a janitor without any construction knowledge? I wouldn't. But, I would
    if I knew that this janitor had obtained a certificate through experience on the job as a construction worker and extra studies on how to build bridges
    and cope with, say, pressure on materials etc. Does a janitor that does his job well deserve respect for it, of course!

    But, maybe we should think about having some contexts defined. And based on the context the software is supposed to operate, define what
    the capabilities and certifications of the developers of this software should be.

    And not all software is context dependent of course, so when a project starts the parts that are important within the context
    should be identified. For instance, the guy that programs your car's ABS system has a higher responsibility than
    the guy writing your air co's soft. Meaning that in extreme weather conditions you can of course freeze to death if your air co
    doesn't work well. But I guess that in these conditions you'll probably die first hitting a tree if your breaks don't work.

    some contexts that just pop to my mind:
    - a medical context.
    - a transportation context, with sub contexts: marine, airplane, road, train.
    - (national) security
    - finance

    I don’t understand the resistance in the software industry, I guess these are growing pains and some people are afraid of growing up. To clean a façade of a historic monument you need qualifications. To clean ancient paintings you need qualifications. Why wouldn’t you need qualifications to write certain types of software?

    How these capabilities and certifications are to be obtained and accredited is another discussion. And with proven capabalities and certifications respect will automatically follow. Software Development isn't easy. A lot of people try to sieze respect by making a lot of wind, but without proof of what they did nor when they did it, and that's exactly the problem.
    By the way, you can't sieze respect, you have to earn it.

    Interesting book on the matter: http://www.stevemcconnell.com/psd.htm
  22. What's the problem with certifications?[ Go to top ]

    Wouldn't you get scared if you knew that your car's ABS system was the

    > first program that its programmer ever wrote?

    No.

    > Would you like it if airplane software was written without any good
    > quality assurance and without any testing, because of time pressure?

    No.

    (Note that these are two completely different questions.)

    > Why do we have such strict regulations for the airplane industry,
    > anyway, because we believe in 'the self-regulating free market'?
    >
    > Or maybe because we don't want to wait for the 'the free market' to
    > become self-regulating only after some real disasters have happened.

    What makes you think this isn't exactly what happened? And is still happening? Of course this is what we believe. Do you think that the day after the Wright Brothers flew Kitty Hawk, that the FAA should have been established? With abosolutely no experience available in the field?

    > Ok, how about a bridge, would you drive over it if it were built by a
    > janitor without any construction knowledge? I wouldn't. But, I would if
    > I knew that this janitor had obtained a certificate through experience on
    > the job as a construction worker and extra studies on how to build bridges
    > and cope with, say, pressure on materials etc. Does a janitor that does
    > his job well deserve respect for it, of course!

    Funny, I'd look for a janitor with a history of successful bridge design and building projects. Certificate or not. Certified != Qualified.

    > But, maybe we should think about having some contexts defined. And based
    > on the context the software is supposed to operate, define what
    > the capabilities and certifications of the developers of this software
    > should be.
    >
    > And not all software is context dependent of course, so when a project
    > starts the parts that are important within the context should be
    > identified. For instance, the guy that programs your car's ABS system
    > has a higher responsibility than the guy writing your air co's soft.

    Here's the key that you're missing. Simply put, the ABS programmer has no more responsibility to the success of the ABS system than the design engineer or the sensor manufacturer. Here's simple example. I have a car with ABS. And amazingly I am completely ignorant as a consumer of several factors. I don't know a) what CPU it runs on b) what language it was written in c) who wrote it d) what tools they used e) whether the source code is maintainable f) whether he names his variables like_this or likeThis or LIKETHIS. None of it. I don't know what the sensors are made of, what gauge wire they use, where they bought their parts. Because none of it matters.

    The overall system must be robust and reliable. Since this is a key design factor in the system, the maker of that system must and will actually test that their design is reliable and robust. The manufacturer is aware of the HUGE liability risk, as well as the moral responsibility of this functioning of this system. If there are any regulations regarding ABS development, I can guarantee you none of them discuss how the software is developed. All they discuss is how this system must function is assorted cases.

    If and when it fails, I certainly won't be cursing Joe Programmer. I will be cursing Ford Motor Company. I will be suing Ford Motor Company. I will tell all my friends to not patronize Ford Motor Company.

    > Meaning that in extreme weather conditions you can of course freeze
    > to death if your air co doesn't work well. But I guess that in these
    > conditions you'll probably die first hitting a tree if your breaks
    > don't work.
    >
    > some contexts that just pop to my mind:
    > - a medical context.
    > - a transportation context, with sub contexts: marine, airplane, road,
    > train.
    > - (national) security
    > - finance
    >
    > I dont understand the resistance in the software industry, I guess these
    > are growing pains and some people are afraid of growing up. To clean a
    > faade of a historic monument you need qualifications. To clean ancient
    > paintings you need qualifications. Why wouldnt you need qualifications
    > to write certain types of software?

    Who says you don't need qualifications? Certification != Qualification. (unless your only qualifaction is certification, of course).

    > How these capabilities and certifications are to be obtained and
    > accredited is another discussion. And with proven capabalities and
    > certifications respect will automatically follow. Software Development
    > isn't easy. A lot of people try to sieze respect by making a lot of
    > wind, but without proof of what they did nor when they did it, and that's
    > exactly the problem.

    50% of the Certified people are in the bottom 50 percentile. We've been through the Certifications rage with the plethora of the MS certs, etc. Do you really think that these raised the bar at ALL in terms of the quality of people in the industry? I was test driving a car and the car salesmen asked me if I thought him getting an MS cert was a good idea. There are good folks out there with certs, but the certs didn't make them good people. There are no doubt thousands of degreed, tested, and certified engineers, doctors, and lawyers who are lousy at their trade. The truly horrific ones are driven out of the profession. Degreed, tested, certified, and fired.

    We can look at recent disasters such as the Arinne V or the Mars probe failures to see that the worst things can happen to even the best people.

    Those industries that create products that present risk to people tend to be heavily regulated by State agencies. State agencies which have the role of certifying the PRODUCTS and the power to apply punitive measures against the manufacturers should something go wrong (such as the recent Firestone Tire debacle).

    The problem is that folks outside of the art are more and more requiring the assistance of those practicing it, and they are unqualified to choose properly. I can completely relate to the problem. For example, folks who know me say I have a pretty good head for this computer stuff, been doing it a long time, yet I would be the exact wrong person to evaluate, say, a Microsoft NT administrator face to face. It would almost solely be based upon references and demeanor. And since neither of those are "certifiable", it's still a crap shoot.

    The real core of this issue is not certifiablity, rather its simple liability.

    No creator of consumer software warrants their software. Nobody will accept the liability for damage of anything on your system. Not ths OS vendor, not the application vendor, not the folks who wrote the drivers.

    Think of the chain of responsibility for a simple keystroke. Keypress sensed by the software in the keyboard, tickling voltages on a wire to be detected by a routine written by the author of the BIOS which is fed to a driver managed by an OS and made available to the application. That one keystroke passes through the hands of FIVE different people. As an application author, you're the last in line. And you're going warrant that the whole thing works?

    I didn't think so.

    My keyboard says "Microsoft" on it, and as a corporation, they warrant that if I push the buttons, that tingly bits of electricity will come out the cord according to Specification THX-1138. They control everything to what I plug the keyboard in to. I don't even know that Microsoft wrote the internal keyboard firmware. They probably subbed it out of Happy Keyboards, Inc., but since it's a tangible, testable, controllable thing, Microsoft can and does warrant it.

    That's why Boeing can warrant a 777. They build and control the entire thing. Every molecule of that thing has a specification, and they know where all of it comes from. Chosen to meet those specifications. Yet, Microsoft, #2 in the US Market Cap, won't warrant that it's simple four function calculator program will work, or that it has any practical purpose whatsoever.

    The more you can control the conditions that a system is going to perform under, the more responsibility you can take for its behavior. Since software is essentially an open book running on an underspecified platform in an unknown environment, authors take essentially no responsibility.

    Software is simply an automated list of instructions. Follow them with care, but use them at your own risk.

    The other key factor is that despite the naggings and whining and moanings of those cursed with buggy software, nobody wants to pay the price that a company like Boeing must pay to certify its software.

    Did you know that Ebay (so I have heard) checksums its data structures in memory to make sure some strange memory brain fart doesn't corrupt their application?

    Can you imagine what would happen if you bid $10, and an alpha particle hit a rogue bit on the amount field of the bid? Ebay apparently does enough transactions that there is enough of a risk for them to warrant taking this extra measure. Does any of your business software do this? Did this ever even OCCUR to you to code something like this in your software?

    Never occurred to me. Why is that? Because the consequences of such a failure do not warrant such action in most domains. Most systems have enough people in the loop to catch these issues, and paper trail to fall back on and repair it.

    And for 99.9% of software out there, the consequences of failure are little more than frustration. For the 0.1% that matter, that software is in a device that's already under a enormous legislative burden because of the consequences should the SYSTEM (software, hardware, etc) fail.

    Software is still young. Really. We are just now in the past few years trying to somewhat make development more effective through the development of things like Patterns and Best Practice. These are both new "industry" words only a few years old. Heck, we aren't even to the "interchangable parts" phase of the industrial revolution. We're getting much closer, but until then, we still have hand crafted parts that are hand fitted together. Despite all of our tools and GHz and technology, we're at about year 1820 of the industrialization path when it comes
    to software.

    So, simply put, we don't have a practice that is certifiable yet. Our domain is VAST in its scope and we have yet come to grips with it. But regardless, we still have an enormous demand for this service, so we stumble along and make do as we go.
  23. What's the problem with certifications?[ Go to top ]

    My eyes hurt just reading the previous posting!
  24. What's the problem with certifications?[ Go to top ]

    to answer your question on the origins of FAA (source http://www1.faa.gov/aboutfaa/History_Brief.cfm):

    "Origins. The Air Commerce Act of May 20, 1926, was the cornerstone of the Federal government's regulation of civil aviation. This landmark legislation was passed at the urging of the aviation industry, whose leaders believed the airplane could not reach its full commercial potential without Federal action to improve and maintain safety standards. The Act charged the Secretary of Commerce with fostering air commerce, issuing and enforcing air traffic rules, licensing pilots, certificating aircraft, establishing airways, and operating and maintaining aids to air navigation."

    Granted, the industry requested regulations, but didn't provide them themselves (in this case the government did).
    The Wright brothers' first airplane 'Wright glider' (1902) and the founding of the FAA (1926) are separated by only 24 years. Only 24 years.
  25. What's the problem with certifications?[ Go to top ]

    First, an apology to Nitin. I accidentally named him, but I meant to name Peter Pilgrim. I still don't understand why Nitin thought Pete's page deserved community attention.

    The Wright brothers' first airplane 'Wright glider' (1902) and the founding of the FAA (1926) are separated by only 24 years. Only 24 years.

    Clearly software engineers have been very fortunate to avoid that same fate, especially since so many decades have elapsed since Turing and Von Neuman. I wonder if Pete has asked himself some important questions:

    1) What upsets him so much about his career that he wants government intervention?

    2) If his government accredited degree is insufficient to distinguish him as able, than why does he feel a government license would be different?

    3) University taught me many silly things including relational algebra, FORTRAN, CISC assembler, OS/2, etc. Almost all of the skills I actually use were learnt in the field or on my own. What makes him think a centrally produced license exam's subject matter would be more relevant than my university classes?

    4) By restricting the talent pool with a licensing entry barrier, does he think firms will be more pressed to seek offshore help?
  26. First, an apology to Nitin. I accidentally named him, but I meant to name Peter Pilgrim. I still don't understand why Nitin thought Pete's page deserved community attention.

    >

    Brian

    Well Nitin did not write the article. He graciously accepted the first draft and asked me to make many changes before publication. This is my own work. He and TheServerSide.com is not responsible for my views.

    > The Wright brothers' first airplane 'Wright glider' (1902) and the founding of the FAA (1926) are separated by only 24 years. Only 24 years.
    >
    > Clearly software engineers have been very fortunate to avoid that same fate, especially since so many decades have elapsed since Turing and Von Neuman. I wonder if Pete has asked himself some important questions:
    >
    > 1) What upsets him so much about his career that he wants government intervention?
    >


    First of all, I think you have grabbed the wrong end of the stick. My article is not about wanting government intervention. That is not why I wrote it. Second, it is not about my personal career either. My article is about my observations of some failures I have witnessed in software projects, it is about some of the conservations I have had in the past with other software developers that I have known in and out of the work place, and on the Internet. There is a bit of frustration in the tone of the article, I would admit to that, but it is more of the feeling of, "Why are software project failing?".

    The tone of the article was about the irritation of projects, when I first drafted it to myself, it was completely negative without any positives then, so I added the other sections to balance the text and to present a more better future.

    > 2) If his government accredited degree is insufficient to distinguish him as able, than why does he feel a government license would be different?
    >

    Again this is not what I am talking about, exactly. There is a mismatch between computer science, as I have known it in a British university, and the actual reality of the business workplace. There is an impedance problem because the information technology industry is a fast moving target. You could argue that the Pascal that I learnt almost fifthteen years ago is not very relevant in the J2EE world, but it is the fundamentals that need to be taught (or lectured) in academic institutions. And as I said in previous post there are employers who don't care what you have read in as a subject, just that you have achieved a particular grade from a respected university, and achieved a stepping stone.

    As far I know governments do not necessarily regulate professionals at least in Britain. Professionals usually have a voluntary self-regulated legal entity or representation group for themselves. Whether the professional respects their own organisation to join it is another thing all together. Of course there are groups that are compulsory to the industry e.g. the practice bar of law, or the medical association, and of course your very own example about civil aviation authorities.

    > 3) University taught me many silly things including relational algebra, FORTRAN, CISC assembler, OS/2, etc. Almost all of the skills I actually use were learnt in the field or on my own. What makes him think a centrally produced license exam's subject matter would be more relevant than my university classes?
    >
    > 4) By restricting the talent pool with a licensing entry barrier, does he think firms will be more pressed to seek offshore help?

    Well maybe all these skills that you mentioned could be in theory centralised and organised into something univeral accredited with support from the top concerns in industry. This can be done without government involvement. The example involves university qualifications. What should exist after the graduate has been in the industry for several years and wants to progress her career? Additionally such a scheme would have to internationalised and be accepted globally. How to go about it? I dont know yet ... but they say nothing is impossible.

    Licensing is a political sensitive issue. I would preferred not to be licensed to work for my own art. Yet I can see that for situations where there is real danger to life and community you might want somebody is accredited. In any case I remember reading the warranty on Java somewhere I thought it said something like, "do not use in a nuclear power plant" ...

    As for the question about off-shore help. This is question of economics at the end of the day and not about licensing. If the profit margins will be increased or the survival rather bankruptcy is the order of the day, then I think more firms will look to outsource IT. This will, of course, effect the running of information technology in those concerns, because the IT department is no longer going to be core to the business. In other words IT will become another service company to the core operation, and that brings all the communication/ design/ value problems back between the supplier and the client.


    I was sitting there one evening at home after a long day's work and watching the television. You can call it writter's jurisprudence, suddenly I saw this new advert (Windows 2003 commercial) appear on the wide box. I was actually dumbfounded. I remember thinking to myself, is this image of me, or us, the real software developers? Are we to outsiders, people who just ad-lib jargon all the time? What is the image of the software guru? Is it sandals and gnashing yellowed canibined teeth beard long like Saddam Hussein and the same as it ever was? There and then I came to conclusion I don't know what we look like at all. I thought about it for a long time, there was an incredible amount of "apple juice" in the stories behind the images of these two guys meeting in the average office to actually start writing. Why were Frank and Ted there? What was the movement got them to that point? I thought of the state of the industry that these two guys were in. What are these guys trying to achieve? Moreover, the contrast between these two guys got my attention, the communication discrepancy cause me to think about my experiences that I bore witness to.

    There is a psychological i_node that the advertisers want the audience to obtain permanently. They want us to always remember. And you know I remembered. I remembered too bloody right, but I wasn't specifically concerned with the brand or the product, the whole experience conjured a whole avalanche of thoughts beyond what the originators had envisaged.

    Peter Pilgrim
  27. There is a psychological i_node that the advertisers want the audience to obtain permanently.

    I don't care how I'm portrayed. I love developing, and I owe my service to who buys it. What Hollywood thinks of developers is irrelevant to me. My favorite portrayals of hackers show the geek for who he is. Only more advances in user interfaces would allow less geeky folk to supplant geeks as developers, and then what will I do? So the geek is a temporary icon, and you seem to think his time has passed. What I don't understand is why you'd want to help change the image of a developer. How would you benefit from an improved image? Do you want to be surrounded by more of the vain folks? Would that really help our craft?
  28. The essential thing to learn in order to be successful in the IT industry is visualizaion. The things you do when you are coding/designing/configuring software have no directly visible connection to the result you are trying to acheive. The lines of code you write in order to display a web page are only linked to the visible result in the the most indirect way, yet you have to be able to 'see' what the result will be as you write that code.

    This means that the essential skill is not learned in any particular kind of schooling. Two of the best developers I have known studied music and art (painting). They learned the particulars of whatever systems/languages on their own as they needed them.

    It also means that you can't define a test which will guarantee that those who past it will be good at it and that those who don't pass it won't. In the past attempts to define 'professional' qualifications have failed because there were always people without the qualification who were able accomplish the desired result. No doubt many people will argue that the long term costs will be higher because the unqualified person is less likely to write 'good' maintainable code by the client that got what they wanted probabely doesn't care. Their goals and costs concerns are almost always about the next quarter or 2 so something cheap that gets the job done is all they want.

    Then of course there are the disasters that business has to pay for that happen despite all of the best qualified/certified people being involved.
  29. Trust me: this is on topic:

    Many successful patent attorneys don't have law degrees (at least not here - dunno about the US). Yet they are very highly paid for legal work in a highly technical legal area, dealing with cases that can be worth hundreds of millions. They start as a graduate trainee at a patent law firm, learn what legal details they need to, and they're very bright people with very good engineering or science background who can pick up things quickly. I believe the same could be true of other parts of law: many lawyers, like developers, are specialists - you don't have to have done a law degree or be an expert on jurisprudence to do a specialist piece of law.

    But I wouldn't pick a lawyer without a law degree, even if I was allowed to. My problem, as a client, is that I don't know whether a given area of law is one where you could do the work without the broad-based skills you get from a law degree, or not. And while I know some lawyer with law degrees suck, I also know that many who can't cut it are filtered out if I only pick those who are qualified.

    This is why those without formal qualifications will start to see their prospects diminish in a couple of decades time, when qualified developers are much more common. Employers, faced with candidates A and B, will go with what's safe and pick the one who's qualified/certified/etc. It requires first that a culture of standard qualifications and certifications to build up, which always happens slowly, but which will happen.


    Sean
  30. But I wouldn't pick a lawyer without a law degree, even if I was allowed to.

    What's more important: the law degree or the bar exam?
  31. But I wouldn't pick a lawyer without a law degree, even if I was allowed to.

    >
    > What's more important: the law degree or the bar exam?

    :) For a barrister or for a solicitor?

    And if you want a patent attorney, do they need to be a barrister?
    Are you sure?

    My point (again) is that outsiders often are not completely sure about the vlue of qualifications and certifications: which is why they often tend to play it safe and so go for certified people. Hence my view that managers will start to tend towards hiring certified IT people: the manager may not understand OO architecture but they do understand what a Bachelor of Engineering is.

    Sean
  32. Very interesting take![ Go to top ]

    I have been seeing the realm of Software development from this angle for several years now, and it amazes me that very few people think in terms of the liability aspect of it.

    You make several statements as to how the car is warranted by Ford, or the plane by Boeing and that you sue/punish the product, not the developer. I think that a lot of the current problems in Software would go away (and quality would improve tenfold) if software companies were regulated into being liable (be it to the public or to an FAA-like agency).

    I don't see how it is different to have software go through several hands (your example of the keyboard vs. the driver/OS/Application). The folks at Boeing do NOT make every piece of software/hardware/other in their planes. These things are subcontracted, etc.... But Boeing still bares the fiduciary responsibility at the end of the day if anything goes wrong. This is enforced by them requiring a very high level of quality from their employees, their subcontractors, etc. I bet if Software products operated on that same premise, some of the charades that take place in today's software world would go away quicker than you can say "lawsuit".

    It is unfortunate that our over-litigious society is becoming a way to ensure quality, but in a world where the $$$ run every single decision (cost-cutting at the expense of quality, for example), the only way to counter some of these half-baked approaches to development is by threatening to make them too expensive.
  33. Thank you[ Go to top ]

    Just wanted to say thank you for all the good advice in this thread. Im a jr. computer science major working a technical co-op position, but I had decided a little while back to get a business minor and pursue an mba after graduation. This thread makes me feel like Im going in the right direction.
  34. The issue is not certification[ Go to top ]

    The issue is not so much with certification. Often, the management fails to distinguish between a hacker and a creative software designer and tends to have a very nebulous view of software architects. Some of it may have to do with the intangible nature of software.

    People with the right back ground are often not identified and introduced into projects at the right time. I have worked on many projects where the typical scenario is as follows.

    A bunch of hackers will produce the initial prototype and then under presuure of delivery the same hackers will wear the architect hat and organically evolve the prototype to a product. Typically, this will work for a while until the product begins to show signs of lack of proper foundation and achitecture. By that time, it's too late to undertake any reengineering effort , especially if it's already being used by customers.
  35. The issue is not certification[ Go to top ]

    Ours must be the only industry where welder is allowed to design an aircraft or a carpenter is allowed to design building, drawing metaphors from other industries. It is difficult to get a deep and precise understanding of the skills and capabilities of software engineers. Only after an engineer has come on borad on a project and worked on it for some time, you can begin to make some realistic assessment of the potential contribution to be made by the engineer. The engineer's role shoiuld be redefined based on the assessment being made. At any cost, he or she be stopped from making poor design decisions that may have far reaching negative effects.

    >
     Well, the real quality to measure is how fast somebody could pick up a subject, build on it, and deliver a software system which is less buggy, maintainable and meets customer requirment.

    A welder could pick up an aircraft design knowledge may be in few weeks, where as a so called "Certified" engineers may take months.

    It is your thought process that matters. I have seen so many MBAs and Computer Science degree graduates who could not understand what the business really needs.

    The business does not care whether you got a degree or how you code. The requirments are plain.

    Deliver a system which does XXXXX ,and extendable to YYYY in NNNN days with in KKK$.

    Here, you got to use your brain to pick up the things needed, I guess these things you cannot read from books.

    As somebody posted earlier

    'size of 1st level cache', 'brain CPU clock' and 'memory access speed'

    is the real difference!!!
  36. The issue is not certification[ Go to top ]

    Ours must be the only industry where welder is allowed to design an aircraft or a carpenter is allowed to design building, drawing metaphors from other industries. It is difficult to get a deep and precise understanding of the skills and capabilities of software engineers. Only after an engineer has come on borad on a project and worked on it for some time, you can begin to make some realistic assessment of the potential contribution to be made by the engineer. The engineer's role shoiuld be redefined based on the assessment being made. At any cost, he or she be stopped from making poor design decisions that may have far reaching negative effects.

    > >
    >  Well, the real quality to measure is how fast somebody could pick up a subject, build on it, and deliver a software system which is less buggy, maintainable and meets customer requirment.
    >
    > A welder could pick up an aircraft design knowledge may be in few weeks, where as a so called "Certified" engineers may take months.

    Few weeks, really! That tells me lot about your knowledge of aircraft design

    >
    > It is your thought process that matters. I have seen so many MBAs and Computer Science degree graduates who could not understand what the business really needs.
    >

    I am not proposing creating a barrier to entry, but existence of bad degreed engineers is no excuse for letting any one in. Do you think the medical profession will allow some one who is not certified to perform heart surgery. May be a little dose of liability is not so bad for our industry. That's likely to be more effective than creating artificial barrier to entry.


    > The business does not care whether you got a degree or how you code. The requirments are plain.
    >

    They don't until they start bleeding with chronic qualilty problems because some hacker left the legacy of a poor design decision made sometime in the past.

    > Deliver a system which does XXXXX ,and extendable to YYYY in NNNN days with in KKK$.
    >
    > Here, you got to use your brain to pick up the things needed, I guess these things you cannot read from books.
    >

    Sure. I agree. But there are things you learn reading too.

    > As somebody posted earlier
    >
    > 'size of 1st level cache', 'brain CPU clock' and 'memory access speed'
    >
    > is the real difference!!!
  37. ABS System[ Go to top ]

    My ABS was written by a programmer on his first project.
  38. Welder designing aircraft[ Go to top ]

    Ours must be the only industry where welder is allowed to design an aircraft or a carpenter is allowed to design building, drawing metaphors from other industries. It is difficult to get a deep and precise understanding of the skills and capabilities of software engineers. Only after an engineer has come on borad on a project and worked on it for some time, you can begin to make some realistic assessment of the potential contribution to be made by the engineer. The engineer's role shoiuld be redefined based on the assessment being made. At any cost, he or she be stopped from making poor design decisions that may have far reaching negative effects.

    This is somewhat analogous to trying to differentiate between a good writer and a bad writer, where it is difficult to come up with a set of objective and tangible criteria to make the differentiation. Although a strong academic foundation is important, I am not sure if certification is the panacea. In real world, you tend to fall back more on patterns and anti patterns you learned on your past projects. A good track record is as important as the acedemic foundation.
  39. Nitin is second guessing society, especially corporate Amerika. If he wants more respect, then he should sieze it. If he can't seize it, then he doesn't deserve it. Seriously, why does anyone deserve more respect than the janitor? During the dot-com boom we were speculatively creating unprofitable applications with wreckless abandon. How much respect would a civil engineer deserve if he did the same with bridges?


    Hi Brian

    Actually I am a British citizen and my experience of corporation of the
    USA is null. I am curious about your spelling for America above.
    Respect is a relative term, it depends on where the observer is
    located. In the article I am refering to two types
    1) Inside the organisation and 2) outside of the organisation.
    The former is essential for delivering a project on time.
    If you are the observer and you are also the chief technical officer
    then I am sure that you will value the work that all your subordinates
    do for the organisation. After all if there is no happiness
    or rather satisfaction in the work place, then we would
    all walk find another job. So to paraphase your example about
    the "janitor". A vice president just walking into an office
    with pleasent "good morning" produces wonders with
    said to a "project manager" as it does to the "janitor" who
    cleans the office. But that is just good manners. The other
    kind of respect in the organisation, is allowing everyone's
    points to be heard.

    If I as a experienced MVC developer said to the business lead
    that this screen design mockup is too complex to implement
    within in 6 weeks and it is going take longer to build it.
    It also requires a lot more server side components to be
    implemented, because need to access more table inside
    in to database then it up to the business lead to listen.
    If he does not or refuses to believe what I said to him,
    then of course we have a problem. If I also said to him
    may be we should redesign the screen, perhaps divide
    it into constituent parts and he refuses, then that is
    up to him.

    This is what I am talking about when I am talking about
    "Respect", I am sure that the civil engineer will be
    listened to because of she knows the necessary state "property
    and conveyancing laws" and has the training and the
    acreditation to back it up. Now software engineering
    or rather Java 2 Architect Certification does not
    provide back-up.

    >
    > I grant Nitin that it is ironic how the dude who writes firmware for a pace maker legally doesn't need a high school diploma, but the nurse's empty bottle of nail polish was designed by an engineer who needed a license. As a free market fanatic, I prefer the lack of entry barrier that we developers enjoy. My brother has an international business degree, and he's a higher paid software architect than I at a firm listed on NYSE. My dad rose to one level beneath vice president of AT&T without a college degree. He started there as an assembly language hacker. So don't tell me about how developers are overlooked. Entry barriers are for anti-competitive wussies. Does Nitin appreciate that a developer is the star of this TV commercial? A housewife has to be shown mopping the floor to star in a TV commercial.

    You're right. The developer, Frank, is the real star of the commercial,
    and I quote myself.

    "One advantage that Frank has in the scene is that he can, at least,
    translate the technicalities into financial reality that Ted can
    understand."

    PS: When I wrote the article. I was not sure if the commercial
    (adverts for UK people) were being shown in the USA. I am pleased
    at my gamble.
  40. Endangered species[ Go to top ]

    We already have a replacement: someone making the equivalent of $12,000/year and living like a king in Bangalore.
  41. Endangered species[ Go to top ]

    We already have a replacement: someone making the equivalent of $12,000/year and living like a king in Bangalore.


    +1

    In the future, there will be no such thing as "Western" programer.
    Asia has great education for enginners, great cost of living, great business climate, etc.

    In the West, education has to be very equal. - regardless of the background or skill - "no child left behind",
    the cost of living and property taxes is high,
    and if you want to hire a programmer in the West you have to pay workers comp, social security, health care and in general hirings are taxed.
    And lets not forget the West tradition of having long meaning less meetings, that just kills productivity.

    Then there is copyright. If one developers a sofware product, it is so easy to break it and revrse it, and now I can sell it for cheaper.

    Every CTO can save on cost of labor by moving staff to Asia.
    In Asia, you get a great home, great salary, great growing profession.
    With shrinking programmer #'s in the West, there is no one to consult.
    So there will be no more geeks, but more admins.

    Let's face it, programming is a hobby, not a paying profession for anyone with self respect.

    .V
  42. Endangered species[ Go to top ]

    We already have a replacement: someone making the equivalent of $12,000/year and living like a king in Bangalore.

    >
    > +1
    >
    > In the future, there will be no such thing as "Western" programer.
    > Asia has great education for enginners, great cost of living, great business climate, etc.
    >
    > In the West, education has to be very equal. - regardless of the background or skill - "no child left behind",
    > the cost of living and property taxes is high,
    > and if you want to hire a programmer in the West you have to pay workers comp, social security, health care and in general hirings are taxed.
    > And lets not forget the West tradition of having long meaning less meetings, that just kills productivity.
    >
    > Then there is copyright. If one developers a sofware product, it is so easy to break it and revrse it, and now I can sell it for cheaper.
    >
    > Every CTO can save on cost of labor by moving staff to Asia.
    > In Asia, you get a great home, great salary, great growing profession.
    > With shrinking programmer #'s in the West, there is no one to consult.
    > So there will be no more geeks, but more admins.
    >
    > Let's face it, programming is a hobby, not a paying profession for anyone with self respect.
    >
    > .V

    Hello Vik

    So, as fellow Jakarta Struts developers, after all we are on the same
    ``struts-dev at jakarta dot apache dot org'' mailing list, you don't think there
    is any chance we can both make a living being Struts developers?

    Programming as the part of the profession that is a descendent of
    pushing cards into the big mainframe may be weaking, both the demands
    of core business keep growing exponentially. "They alway want more
    features and more demanding complex solutions." So in antefact there
    has to be more need in the future for good technical analyst. You
    cannot be a good technical analyst if you know zilch about
    programming. I think there will be a demand developers as long
    business want to compete against themselves. Who do you trust to
    do the work in the end?

    The question is who will do you want to do design, who codes, and who
    will provide support and on-going maintenance as always.

    As for being in the hobbyist domain. There are many opensource projects
    that started out as typical programmer's itch and yet it is
    "big business" who driving recruitment for people who have
    opensource experience. You do not have to surf very far to find
    a vacancy for a developer who understands STRUTS, Tomcat, or JBoss.

    And Vik what is the future of your own company BaseBeans if you
    actually think that programming is dead? Who are going to train
    in the future? A conundrum n'est pas?

    Peter Pilgrim
  43. Two Cent[ Go to top ]

    Having experience doesnt put you in the elite class. You can have 10 years 'experience' but not have a notion of what you are talking about. YOu probably just spent those 10 years at the same company, at the same desk with the same IT certificate that you got in 1985 for all to see.

    If your good then your good.....otherwise your either average and hold you own or at worst....bloody useless....thats it
  44. Endangered species[ Go to top ]


    > And Vic what is the future of your own company BaseBeans.com if you
    > actually think that programming is dead? Who are going to train
    > in the future? A conundrum n'est pas?
    >
    > Peter Pilgrim

    baseBeans.com and my competitors should be doing a lot better financially, is all I am saying. (maybe I should say baseBeans.com is doing great, but... ) It aint easy to compete, and it used to be easy.
    Anyway, I sometimes have more fun complaining and blaming my local politicians for their taxes on business. I have to file a tax report in 12 States!!!!

    Good article!

    Vic Cekvenich
  45. Endangered species[ Go to top ]

    As for being in the hobbyist domain. There are many opensource projects

    > that started out as typical programmer's itch and yet it is
    > "big business" who driving recruitment for people who have
    > opensource experience. You do not have to surf very far to find
    > a vacancy for a developer who understands STRUTS, Tomcat, or JBoss.

    I can speak to at least the first one or two of your examples ... maybe my insights might be interesting :-). And, in fact, my open source experience was very critical to getting my current job at Sun. But, there is more to making a *career* of software development than what you've done, or what technologies you understand. In my case, it has come from the fact that I have a somewhat unusual background compared to a lot of geeks. You see, my university degree is in Business Administration (with an emphasis in Accounting).

    All of the talk about the 10x productivity difference between the "stars" on your development team and everyone else really understates the impact of the most critical people in the project -- the ones that can translate user requirements into technical requirements (and back again as the development progresses). In a good project, this will typically be the architect that decides the actual shape of the project, and then delegates the work. Interestingly (and if you've ever contracted for development services from a third party consultancy, you'll know this already) it's the architect's time that is the most expensive.

    I've seen a lot of projects, at all sorts of different size scales, and a depressingly large percentage of them fail to deliver what was promised. Sometimes, that failure was due to overreaching what was technically possible at the time, or shortchanging the investment in the development team, but in at least 80% of the failure cases I've seen, the key problem was the disconnect between the user's actual requirements (remembering all the while that most users have no clue at how to articulate those requirements clearly) and the developer understanding of those requirements. The person who can translate between the users and the developers is critical.

    Now, can you succeed at this translation role if you don't understand the vocabulary and day-to-day needs of your users? Not a chance. Far from looking down our noses at "mere users", we geeks need to understand that *their* world is just as complex as ours, full of its own arcane terminology and rituals, but (most importantly) very different in the way they approach problem solving. They just don't *think* like we do! But that's ok, especially when they are paying the bills :-).

    Struts, for example, was very deliberately designed to appeal to my own personal target market: IT managers who wanted a solid, stable, and supported platform for building web applications that (yes) improved the state of the art, but -- more importantly from their perspective -- would not be a risky decision that would leave the manager selecting it out in left field. Thus, in addition to all its technical attributes, we deliberately focused on creating a supportive and friendly community around Struts. The rest (75,000 downloads per month from Apache's main site, plus countless redistributions from mirros, the largest user mailing list at Apache, seven books totally focused on it plus chapters in pretty much every book in the field, support by basically every relevant IDE and tool) is at *least* as much due to the focus on user needs as it is to technical magic.

    How did I know what they needed? Simple -- I avoided the trap of an education totally focused on technology, and got a business degree instead. The technical stuff I could learn myself (either from books, or on the job as I started out). An understanding of what was really important to the people writing my paycheck (or paying for me as a contractor) was where I needed to spend some quality learning time.

    I'll close this little essay with advice that I gave to my son a couple of years ago, when he was trying to figure out his future education path (he supports Debian users, and is a very successful PHP developer, but I love him anyway :-):

    * Beyond the fundamental classes that will teach you the disciplines
      required to be a successful programmer, a Computer Science degree is
      not going to help you be really successful. Yes, you can become an
      acknowledged master at whatever technical discipline turns you on, but
      Moore's Law pretty much guarantees that any basic technical skills you
      acquire while pursuing a four-year degree will be obsolete by the time
      the ink on your diploma is dry. Two year technical diplomas give you
      a *little* more time, but certainly not enough to stake a career on.

    * The most important people to get to know are the ones that are going to be
      paying the bills. Show them that you understand *their* problems, and can
      translate those problems into technical solutions, and you will always be
      in a premium position. Wages for technical skills in *any* field are always
      driven down by an increase in supply (as we're seeing here -- even if the
      supply increase was in the US we'd see downward pressure on salaries). People
      who understand how to successfully translate needs into products are always
      going to command premium compensation. For me, a business degree has proven
      absolutely critical to my success -- not because I still know how to create
      an Income Statement (when *I* took Principles of Accounting, we still did it
      all by hand :-), but because I learned about timeless principles like ROI and
      the fact that depending on your users to upgrade to the latest and greatest
      software platform every couple of months is a practical impossibility. You
      had better offer stability and support for what you created in the first
      place (which has translated into Struts evolving slower than many packages,
      but that's just fine with lots of the users).

    * Plan on re-learning pretty much everything about the technologies you are
      utilizing at least ten times during your career (I'm only up to four so far,
      but the rate of change is still accellerating). It's fine to be passionate
      about some particular technology that excites you, but (let's face it) anyone
      passionate about the fantastic innovation that a Teletype machine was in my
      high school years (110 baud, paper tape for persistent storage -- but I could
      dial in and work remotely!) had better have gotten over that passion and
      learned something else in the mean time.

    Fortunately for my son Matt, he's been listening to me (imagine that :-), and has been focusing on learning about what people are willing to pay you a *lot* to know, in addition to all the fun technical stuff. As a result, he's already been so busy at web development that he's got more disposable income than I do (albeit with lower expenses :-). But he's going to have no problem being in incredible demand for an entire career here in the U.S., because his skills are not going to become obsolete.

    I hope that thinking about these ideas can benefit a few other developers out there who might be faced with the idea that their skills look like they are disposable (geeks are just learning what every other industry in the last 50 years have learned; supply and demand drives prices). Technical skills *are* disposable. So go learn some skills that are not!

    Craig McClanahan
  46. >> Endangered species[ Go to top ]

    Computer Science degree is not going to help you be really successful


    I cannot agree. Without proper computer science degree you will not be able to understand the whole system. You will not be able to get the real whole picture of the problem. You will not have the background knowledge of the whole IT. I spent 5 years studying IT. From resistors, capacitors and transistors to smalltalk, OO and distributing computing. It really helps. I can talk with network guys, system admins, SW developers, telecommunication guys, HW people and electricians. Little bit with physics. The proper science degree (IT, chemistry, building, engineering ...) rules.

    But you found very valuable point. Business degree. It is very important. It is very useful. Especially for technicians. Guys, go for it. The time of managers without proper technical knowledge / degree is gone. But with only technical degree you probably will not be a good manager. Go for business degree.

    I am lucky man. I have MSc in IT and general MBA. I am able to speak with business people and with technicians. It is very useful.

    If I can recommend a carrier plan here it is:

    - finish your MSc in IT (5 years)
    - try to find any part job in 4th or 5th year to get an experience;
         even for free;
         try to find a job with cool technologies; see job adverts
    - after your MSc start to work for full time for some cool bigger company
    - start with your MBA or MCom (3-5 years); correspondent university
    - still work on your experience;
         try to work on coolest technology in best company
         try to get some certificates; it is very sexy in your CV
    - finish your MBA or MCom
    - try to get the lowest management position
    - try to get the higher management position
    - try to get CEO position
    - pension
    - death
    - whatever you want
    - ......
  47. >> Endangered species[ Go to top ]

    Computer Science degree is not going to help you be really successful

    >
    > I cannot agree. Without proper computer science degree you will not be able to understand the whole system. You will not be able to get the real whole picture of the problem. You will not have the background knowledge of the whole IT. I spent 5 years studying IT. From resistors, capacitors and transistors to smalltalk, OO and distributing computing. It really helps. I can talk with network guys, system admins, SW developers, telecommunication guys, HW people and electricians. Little bit with physics. The proper science degree (IT, chemistry, building, engineering ...) rules.
    >
    > But you found very valuable point. Business degree. It is very important. It is very useful. Especially for technicians. Guys, go for it. The time of managers without proper technical knowledge / degree is gone. But with only technical degree you probably will not be a good manager. Go for business degree.
    >

    If I have been asked in the past whether it is worth having a computer science degree. I cannot honestly answer the question, because I never read a pure computer science myself.

    I think just a computer science degree is relevant only if you want to go the road of C. Hoare / Djistrka / Sedgewick (Algorithms), as in the study of advanced computer software research. If you are advancing the state-of-the-art of artifical intelligience, image pattern recognition, sorting, searching, or even chip design then it is relevant.

    If you only ever wanted to read one degree from a university, then get a subject that has computer science with something else, X. For example let X be international studies, business studies, biotechnology, management, politics, law, sociology, medicine, or humane studies such modern language, art, philosophy. Even back in the late 1980's there was a trend to create modular degrees. It is well worth researching some of these prospectuses if you aiming to start an IT career after college, university.

    Just be aware that some of degrees are not worth the paper they are printed on in eyes of some very savage and critical employers. In the England there still appears to be an cultural elitism that after you graduate from a university certain employers will only recruit those candidate who graduate from a so-called "red brick" university. Unfortunately this kind of prejudice still prevales in Britain, where some big concerns will also look at the number of A-level (high school grades) when the candidate has a very good honours degree. For example a new graduate might be required to have honours degree, a first (a 1), or upper second division ( a 2-1 ) from say Oxford, but be expected to have A or B grades in say Maths, Physics, Chemistry, Business Studies.

    If the former applies to you, and you meet the criteria then that is great, then you probably don't have to worry about getting a job after a degree. If it doesn't then I wouldn't worry too much about it anyway. As I said before, a certain flavour of elitism prevales, but consider this a little nutshell. A lot of people who have successfully joined a gradute recruitment scheme, be it an investment bank, or software house, have left their first employer after two or three years. What does that tell you about gradute recruitment schemes for the majority of candidates? Only if you are the rarity, singled-out right there and then to be next CEO then such schemes are valid, otherwise, I think, that they are useless. In other words they are great stepping stones in a career. Why do gradutes leave such schemes? For the majority there is a lack of interest, or a change of career direction, or the scheme is not all it was talked up to be. Majority of these participants do say that they have learnt alot about business (both in reality and in cynicism).

    The reality of business is that every employer that is out there recruiting new college / university graduates will claim that they are the "Best Employer". Obviously this cannot be true. Some company out there has got to be a poor employer, but they are never ever going to admit it. Your life is not over if you are unluckly enough to end up working for Poor Acme Ltd. There is always a way in IT. If you don't like then just leave. A poor company will tend to recruit less talented individuals if it never looks to change its internals,
    and law of competitions will tend for it to go out of business quicker than
    its nearest rivals. Which is why competition is fierce for graduates and why
    this cheat-mode of "red brick" exists, since the human resource department dont have the time to get to know individuals in person, especially of hundreds or even thousands of application forms to process.

    If you do not have the best university degree and if you do not have great A-levels you can still make it in the IT, but you have to work a bit more harder and act a bit tougher initially than some of the lauded talent "red-brick" cliche. Afterall education is for life. Once you get into the IT profession, to progress you need to think about jumping a series of stepping stones. This is not the same as scaling a company promotion ladder. It is quite different here, progression is learning about the newest technology, business, the users, and the applications. It is basicly "relearning for life".

    All I'm saying that a pure "computer science" degree on its own is not enough.

    Peter Pilgrim
  48. >> Endangered species[ Go to top ]

    Oh I forget to define the term Red Brick university

    This would be the top ten in Britain including

    Oxford University
    Cambridge University
    Imperial College London
    UCL - University of London
    UMIST - University of Manchester
    Leeds, Birmingham, Sheffield
    Cardiff University
    etc

    Or just try this wiki http://en2.wikipedia.org/wiki/Red_Brick_university
  49. CO-OP Programs and education.[ Go to top ]


    > If I can recommend a carrier plan here it is:
    >
    > - finish your MSc in IT (5 years)
    > - try to find any part job in 4th or 5th year to get an experience;
    > even for free;

    I'd like to put in a plug for my alma mater Northeastern University in Boston. Their program is a 5 year Bachelors in which you do CO-OP every other semester or so. So, when you graduate you have about 2 years of real, hard-core, experience. I myself had the chance to work on aircraft simulations in the early 90's and Northeastern even has a international co-op program which allowed me to do a paid intership at Deutsche Aerospace in Munich, Germany. Companies love it because it is a source of cheap, unrisky, labor.

    I know there are other schools in the country that have such a program, but, Northeastern's is the best.

    Bill
  50. >> Endangered species[ Go to top ]

    still work on your experience;
         try to work on coolest technology in best company
         try to get some certificates; it is very sexy in your CV
    - finish your MBA or MCom
    - try to get the lowest management position
    - try to get the higher management position
    - try to get CEO position
    - pension
    - death
    - Nirvana........
  51. Endangered species[ Go to top ]

    As for being in the hobbyist domain. There are many opensource projects

    > > that started out as typical programmer's itch and yet it is
    > > "big business" who driving recruitment for people who have
    > > opensource experience. You do not have to surf very far to find
    > > a vacancy for a developer who understands STRUTS, Tomcat, or JBoss.
    >
    > I can speak to at least the first one or two of your examples ... maybe my insights might be interesting :-). And, in fact, my open source experience was very critical to getting my current job at Sun. But, there is more to making a *career* of software development than what you've done, or what technologies you understand. In my case, it has come from the fact that I have a somewhat unusual background compared to a lot of geeks. You see, my university degree is in Business Administration (with an emphasis in Accounting).
    >
    > All of the talk about the 10x productivity difference between the "stars" on your development team and everyone else really understates the impact of the most critical people in the project -- the ones that can translate user requirements into technical requirements (and back again as the development progresses). In a good project, this will typically be the architect that decides the actual shape of the project, and then delegates the work. Interestingly (and if you've ever contracted for development services from a third party consultancy, you'll know this already) it's the architect's time that is the most expensive.
    >
    > I've seen a lot of projects, at all sorts of different size scales, and a depressingly large percentage of them fail to deliver what was promised. Sometimes, that failure was due to overreaching what was technically possible at the time, or shortchanging the investment in the development team, but in at least 80% of the failure cases I've seen, the key problem was the disconnect between the user's actual requirements (remembering all the while that most users have no clue at how to articulate those requirements clearly) and the developer understanding of those requirements. The person who can translate between the users and the developers is critical.
    >
    > Now, can you succeed at this translation role if you don't understand the vocabulary and day-to-day needs of your users? Not a chance. Far from looking down our noses at "mere users", we geeks need to understand that *their* world is just as complex as ours, full of its own arcane terminology and rituals, but (most importantly) very different in the way they approach problem solving. They just don't *think* like we do! But that's ok, especially when they are paying the bills :-).
    >
    > Struts, for example, was very deliberately designed to appeal to my own personal target market: IT managers who wanted a solid, stable, and supported platform for building web applications that (yes) improved the state of the art, but -- more importantly from their perspective -- would not be a risky decision that would leave the manager selecting it out in left field. Thus, in addition to all its technical attributes, we deliberately focused on creating a supportive and friendly community around Struts. The rest (75,000 downloads per month from Apache's main site, plus countless redistributions from mirros, the largest user mailing list at Apache, seven books totally focused on it plus chapters in pretty much every book in the field, support by basically every relevant IDE and tool) is at *least* as much due to the focus on user needs as it is to technical magic.
    >
    > How did I know what they needed? Simple -- I avoided the trap of an education totally focused on technology, and got a business degree instead. The technical stuff I could learn myself (either from books, or on the job as I started out). An understanding of what was really important to the people writing my paycheck (or paying for me as a contractor) was where I needed to spend some quality learning time.
    >
    > I'll close this little essay with advice that I gave to my son a couple of years ago, when he was trying to figure out his future education path (he supports Debian users, and is a very successful PHP developer, but I love him anyway :-):
    >
    > * Beyond the fundamental classes that will teach you the disciplines
    >   required to be a successful programmer, a Computer Science degree is
    >   not going to help you be really successful. Yes, you can become an
    >   acknowledged master at whatever technical discipline turns you on, but
    >   Moore's Law pretty much guarantees that any basic technical skills you
    >   acquire while pursuing a four-year degree will be obsolete by the time
    >   the ink on your diploma is dry. Two year technical diplomas give you
    >   a *little* more time, but certainly not enough to stake a career on.
    >
    > * The most important people to get to know are the ones that are going to be
    >   paying the bills. Show them that you understand *their* problems, and can
    >   translate those problems into technical solutions, and you will always be
    >   in a premium position. Wages for technical skills in *any* field are always
    >   driven down by an increase in supply (as we're seeing here -- even if the
    >   supply increase was in the US we'd see downward pressure on salaries). People
    >   who understand how to successfully translate needs into products are always
    >   going to command premium compensation. For me, a business degree has proven
    >   absolutely critical to my success -- not because I still know how to create
    >   an Income Statement (when *I* took Principles of Accounting, we still did it
    >   all by hand :-), but because I learned about timeless principles like ROI and
    >   the fact that depending on your users to upgrade to the latest and greatest
    >   software platform every couple of months is a practical impossibility. You
    >   had better offer stability and support for what you created in the first
    >   place (which has translated into Struts evolving slower than many packages,
    >   but that's just fine with lots of the users).
    >
    > * Plan on re-learning pretty much everything about the technologies you are
    >   utilizing at least ten times during your career (I'm only up to four so far,
    >   but the rate of change is still accellerating). It's fine to be passionate
    >   about some particular technology that excites you, but (let's face it) anyone
    >   passionate about the fantastic innovation that a Teletype machine was in my
    >   high school years (110 baud, paper tape for persistent storage -- but I could
    >   dial in and work remotely!) had better have gotten over that passion and
    >   learned something else in the mean time.
    >
    > Fortunately for my son Matt, he's been listening to me (imagine that :-), and has been focusing on learning about what people are willing to pay you a *lot* to know, in addition to all the fun technical stuff. As a result, he's already been so busy at web development that he's got more disposable income than I do (albeit with lower expenses :-). But he's going to have no problem being in incredible demand for an entire career here in the U.S., because his skills are not going to become obsolete.
    >
    > I hope that thinking about these ideas can benefit a few other developers out there who might be faced with the idea that their skills look like they are disposable (geeks are just learning what every other industry in the last 50 years have learned; supply and demand drives prices). Technical skills *are* disposable. So go learn some skills that are not!
    >
    > Craig McClanahan

    Wonderfully put. Every college-age kid should read that post! I don't think it's necessarily bad to have a cs degree, but it's not essential. I've been in IT only 7 years and I'm on my 4th set of technologies. I've come to the conclusion that I'll never be able to keep up if I want a life outside of my career. I'm not all doom and gloom about the future of U.S. IT but if you're dream is to sit in the corner and punch out code all day, without the desire to develop business skills, then you'll be the one whose replaced with off-shore talent, even if you're 10x the coder that the other guys on you're team are. Business know-how and soft skills are the path to success, even for IT folks.

    Mike
  52. Shooting Endangered species[ Go to top ]

    I avoided the trap of an education totally focused on technology, and got a

    > business degree instead. The technical stuff I could learn myself (either
    > from books, or on the job as I started out).

    The reverse also applies: I have a MSc in comp sci and the business stuff I can learn myself. I think our main point of agreement is that a common mistake people make is thinking that you can get by as a developer without understanding the business (or vice-versa as a BA)

    > * Beyond the fundamental classes that will teach you the disciplines
    >   required to be a successful programmer, a Computer Science degree is
    >   not going to help you be really successful. Yes, you can become an
    >   acknowledged master at whatever technical discipline turns you on, but
    >   Moore's Law pretty much guarantees that any basic technical skills you
    >   acquire while pursuing a four-year degree will be obsolete by the time
    >   the ink on your diploma is dry.

    This is completely untrue. Moores Law is utterly irrelevant here - it's about the doubling the density of transistors on a piece of silicon. Your claim is equivalent to saying that having stronger steel these days makes all the basic technical skills of civil engineering obsolete.

    10 years ago my university was teaching functional programming, OOP, RDBMS systems (& SQL), how OS's work with an example of Unix, fundmental algorithms and datastructures, etc. That's most of the comp sci major, and these are all just as relevant now as then.

    Universities shouldn't be teaching you the latest whiz-bang technology: they should teach you fundamental skills and the important concepts. If you really understand transactions, and networks, and OOP, you'll find EJBs are easy. If you don't fully understand transactions, or networks, or OOP, then when you try to learn EJBs you'll just ape someone else's examples without really understanding them, and you'll create a hard-to-maintain disaster that fails to scale.

    > * Plan on re-learning pretty much everything about the technologies you are
    >   utilizing at least ten times during your career

    Only if your understanding is shallow, and you don't see the fundamental concepts hiding beneath the surface, will you need to relearn everything each time. Which is why I think you're dead wrong about education: you need to understand at a deep level the concepts underlying the technologies in order to able to rapidly shift between technologies that *look* different, but are really very similar. You don't *need* a degree in comp sci to have that foundational knowledge: but it really helps.

    C++ to Java is a shift of OO to OO. Java to C# ditto. The GoF Design Patterns have been identified, and seem quite stable across technologies. Have you not noticed how the trendy new .Net is just like J2EE? The only technological *revolutions* I've seen are the web and xml: pretty much everything else is evolution.

    Now people are talking about AOP: that is a conceptual shift, but that's not very new either. Gregor came out from xeroc parc and demo'd AOP to us at my comp sci dept almost 5 years ago, it'll be at least another 2 years before it hits the mainstream in a major way.

    Yes you have to keep learning, yes things will change, yes the trendy acronyms of 2008 will not be the trendy acronyms on my CV now. But I think you are simply wrong in your claim that people will have to "re-learn pretty much everything about the technologies you are utilizing at least ten times".


    Sean
  53. Shooting Endangered species[ Go to top ]

    Craig: ...Moore's Law pretty much guarantees that any basic technical skills you acquire while pursuing a four-year degree will be obsolete...

    Sean: This is completely untrue. Moores Law is utterly irrelevant here - it's about the doubling the density of transistors on a piece of silicon.

    What Craig said is true. Moore's Law does apply to software engineering. Moore's law isn't just about density; it's also about element count (and therefore about complexity). A zoologist knows that with increasing neuron count comes increasingly complex behavior (and therefore increasingly sophisticated strategies). Moore's Law made it possible for us to switch from C++ to Java. Moore's Law is relevant to anything that relies on digital equipment.

    Universities shouldn't be teaching you the latest whiz-bang technology: they should teach you fundamental skills and the important concepts.

    You're welcome to your opinion. Obviously your kids and mine will be going to different colleges.
  54. Shooting Endangered species[ Go to top ]

    Craig: ...Moore's Law pretty much guarantees that any basic technical skills you acquire while pursuing a four-year degree will be obsolete...

    >
    > Sean: This is completely untrue. Moores Law is utterly irrelevant here - it's about the doubling the density of transistors on a piece of silicon.
    >
    > What Craig said is true. Moore's Law does apply to software engineering. Moore's law isn't just about density; it's also about element count (and therefore about complexity). A zoologist knows that with increasing neuron count comes increasingly complex behavior (and therefore increasingly sophisticated strategies). Moore's Law made it possible for us to switch from C++ to Java. Moore's Law is relevant to anything that relies on digital equipment.

    I'll retract, in part, to a more defensible position: Moore's law is not very relevant here. And I dispute your claim about complexity.

    It is the same as arguing that having better steel makes knowledge of civil engineering irrelevant every 18 months. Give it enough time, and changes to fundamental materials will make a difference - were steel 100 times stronger then engineering would change a lot. But as materials have become better over the last 50 years highway overpasses and bridges have not changed very much (with a few notable exceptions). OOP came along in the seventies, and the ideas behind why you should do OOP are as true now as then. The move from C++ to Java is a move within the OOP paradigm - and yes it does mean doing automated garbage collection, but much of that is due to advances in how good things like JIT compilers are rather than advances in raw machine speed.

    I've met the "more transistors means more complexity" argument before: Kurtzweil (sp?) wrote an entire book based on it in which he assumes that as Moores Law makes computer more complex than us, AI will just happen. It's a mistake. Look at machine translation (for example): Moores law means we can now translate Russian to English badly in milliseconds, cheaply, instead of translating Russian to English badly in seconds, on expensive hardware (as was the case 20 years ago). We aren't getting much better at machine translation, we're just getting faster. Look at SQL, for example: it's a stable technology. Look at OOP, for example: it's a stable technology.

    > Universities shouldn't be teaching you the latest whiz-bang technology: they should teach you fundamental skills and the important concepts.
    >
    > You're welcome to your opinion. Obviously your kids and mine will be going to different colleges.

    <shrug> Given that division you leave my kid the option to go to MIT or Carnegie Mellon or Cambridge or... well, any other decent comp sci dept you can name, since the view I express is standard to comp sci pedagogy. If you wish to avoid such universities as not knowing as much about how comp sci should be taught as you do, that is of course up to you.

    Sean
  55. Endangered species[ Go to top ]

    Off-shore models are returning mixed results.

    Some companies are starting to realize that moving assets off-shore does not necessarily save money. There are a lot of hurdles involved with doing software development this way.

    As the trend for off-shore eventually fades, we'll probably see a successful model that incorporates both on-shore and off-shore resources. Indeed, the company I work for now takes this approach. In fact, we have a few people here from India who, in addition to their regular duties, help interface with our off-shore groups.

    In the meantime, we also have a very active development group here in the States. However, I suspect that much of the reason we do things this way is because we're an international company anyway. Why not use programmers in India or China if your already a business presence there?

    But just because salaries are cheaper doesn't mean TOC decreases. I think that's the failing with the current trend. They've found one aspect is cheaper but don't look at the total costs. I've heard some nightmares from some of my former colleagues whose development efforts are almost exclusively off-shore. There are a lot of complaints about the quality of the code and the amount of time and effort it takes to deliver an application. I suspect language barriers, time differences, and just general difference accounts for much of this. If the guys in my office are any indication of the talent in India, it's certainly not due to a lack of ability.

    Off-shore resources can be leveraged and I see them as a reality for future business. However, they are not a silver bullet to solve all development problems. Any company going exclusively off-shore now will no doubt be hiring software developers back within a few years.

    But you can bet that IT spending will never see dot-com era excesses again. I think the job market and expectations are going to finally balance.
  56. The Origin IT Culture[ Go to top ]

    I think it may be more useful to look more in depth as to why "business value" is lost in translation. In an article I read in Strategy & Business a year ago, the statistics showed rarely is CIOs, and CTOs brought in early and actively engaged in business strategies. The responsiblity for communicating business value really begins there, without this initial involvement from the top, the rest of IT department will only have a perfunctary understanding at best.


    -Tom

    ps The commercials IBM/Microsoft depicts business leads without technical understanding in worse light, than techies without business understanding. (It is no longer cool for a manager to claim he/she is technically uninclined.)
  57. Why can we test doctors, lawyers, and physical engineers for competence?

    Simple. Their problem domains are well defined, well documented, well researched, and typically expanding slowly on very few fronts. When new discoveries are made they are well published and much celebrated.

    Software Engineering as a discipline is in its infancy, much like the practice of Medicine was in the 1800's, possibly even earlier.

    Though there is no way to quantify it now, I believe our problem domain is expanding faster than we are establishing the best practiced solutions to our domain problems.

    That, my friends, is the dilemma we face. Will humanity master this domain of expertise? Time will tell. Will it do so in our life spans? Time will tell.

       Regards,
       -Jon
  58. Why can we test doctors, lawyers, and physical engineers for competence? Simple. Their problem domains are well defined, well documented, well researched, and typically expanding slowly on very few fronts.

    Do you believe software engineering is a dysfunctional craft in need of government intervention? If incompetent developers are killing folks, then where are the bodies?
  59. Software engineering, as a discipline, is very new. Thus it lacks the formal/institutional procedures of older disciplines. This will change, and in our lifetimes.

    First: even if you're right about the problem domain, a poorly understood problem domain is not sufficient to prevent qualification:
    Doctors were qualified by universities for hundreds of years before they were actually any damn good at what they do, and in certain cities they managed to prevent the unqualified from working via a guild structure. The University of Bologna, for example, was based around a medical school that is over 500 years old. Qualifications, and limits on access to industry based on those qualification do not require a well-understood problem domain.

    Second: we can see other examples of new industries.
    In 1920 you didn't need a qualification to be an airplane mechanic, knowing how a aeroplane worked was skill enough. Now having unqualified people servicing commercial airplanes would be seen as horrific.


    Sean
  60. EXCERPT: It is my view that all stakeholders should be a part of the software design and analysis committee. Moreover, they should take far more active involvement and oversee the development of long-term critical projects. Instead of creating a business process that inserts an intermediate layer, a liaison between IT and the core business, these two should constantly be in direct communication, more often than less. On the other hand it is up to the developers and technical people to become more involved with the core business.

    In the software vendor world, the role of the product manager (a.k.a requirement analysts) is the important missing ingredient the author makes reference (see above). This is a critical function, since this is the role that maintains direct communication with the development teams, representing the needs of multiple stakeholders for the project. This role requires not only technical knowledge, but knowledge of business requirements and their priorities.

    I wholeheartedly agree that development staff should be more involved with understanding the core business for which they are developing applications and solutions. The results speak for themselves. Software built by an engineer that understands the context and user profile of the end-user is often met with high user acceptance.

    The product manager should be a vital source for the business context of the solution, and can provide guidance in many ways before and during a project. I find "over-designing" a software solution is more common than most believe. To illustrate using a non-software example, an engineer may "build" an unbreakable coffee pot, using expensive materials and elaborate designs, to meet a requirement that the coffee pot should not break. The real business issue is about user safety, and other (less costly) design solutions can be considered when the real requirement and context is properly presented to the engineer (e.g. heater "shut-off switch" when the pot is empty).

    What are the true business requirements that the solution must be built to meet? Why is this a requirement? What is the CONTEXT of the solution? Is this coffee pot going to be on an airplane, or in an office kitchen? The product manager should be able to offer requirements set in the appropriate business context. I find the best designers/developers will ask these types of questions.

    In summary, it is my opinion that one of the largest steps a software development professional can do to eliminate existing software developer stereotypes is to work to understand "why" something has to be built and understand the "context" for which it needs to be built, before focusing on "how" it is to be done. Sit down and have a good chat with your product manager/requirements analyst (early and often!). Let them find the answers or obtain supporting research for you if not readily available. You'll benefit in more ways than one.

    Cheers,
    Michael Salerno
    President, Boston Product Management Association
    http://www.bostonproducts.org
  61. In summary, it is my opinion that one of the largest steps a software development professional can do to eliminate existing software developer stereotypes is to work to understand "why" something has to be built and understand the "context" for which it needs to be built, before focusing on "how" it is to be done.

    Business analysis is surely crucial to developer's career growth, as a way to appear to his stakeholders as more than an extension of his computer. That's the social aspect of business analysis, which today's software architects are so keenly aware of as a way to impress superiors. But there is also an emerging structural aspect of business analysis. In some (most?) domains, code generation or globalization might devalue all but the most abstract chores. Business analysis could become a survival skill -- the only way to demand a fine wage.

    Hand coding is a niche of diminishing worth. I make 30% less than I did three years ago, even though my engineering skills and productivity have grown immensely. Sometimes I think my ability to relate with analysts and managers is the only reason I'm still employed. This extended role doesn't come naturally for me. I'm much more at ease with my machine, and I miss the days of pure coding. But I'm learning that talent is more than familiarity with tools.
  62. Bring on a proper accreditation[ Go to top ]

    I am still wondering why I need a registered, qualified architect, a master builder who is also registered and qualified to complete an AUD $300K renovation on my house when anyone who can win the business (even on mult-million dollar projects) is allowed to build an IT system or call themselves a software engineer/developer...!?!? and there is no legal framework or restriction on how the project is run, who works on it...it is strictly buyer beware!

    Can you imagine a engineer appearing in a court case to defend you on a criminal charge! Lawyers are free to work on IT projects as developers!

    A simlistic view, but a worrying thought.
  63. Bring on a proper accreditation[ Go to top ]

    Lawyers are free to work on IT projects as developers!

    CNN last month had something to say about licensing programmers:

    "Executives there already have established working groups to advise the Homeland Security Department on subjects that include how to set up early-warning networks and encourage companies to design better software. One early idea under consideration: professional licenses for software writers, like those for doctors and engineers."