Key quote: "While people typically think of programmers as coders, whose main talent lies in writing the arcane syntax of programming languages. I think that their main talent lies in their ability to analyze, troubleshoot, and solve problems. Code is just the physical manifestation that culminates the thought process of the programmer."
I think it's relatively truthful to say that they'd practically constitute a programmer if they were able to do this. If a programmer is paid $40/hr to complete something in 1 hour and it takes a "business analyst" being paid $20/hr to complete the same logic without code in 2 hours, it makes much more sense to pay the programmer overall... It's really all assumptions up until there is something to disprove the theory.
only the code is not accessible to the busines owner to audit, validate or change. Presumably the business analyst would produce something more accessible. Also, the 'extra bits' [aka. modeling bias] added by the programmer may or may not have been vetted by the owner.
I do not believe that today's business analysts are what is needed and I agree that programmers have to step in many times to do their work. I am just saying that in principle, that is what the BA should do. If these are core skills of programmers, maybe that is our future vocation, when a language hi-level enough comes around.
"... Shouldn't a good business analyst be able to do this? Given a business with no information system, shouldn't policy be consistent anyway? ..."
4GL's tried to solve this problem. Didn't work. I suspect this approach is always at best a weak solution to a hard problem, not because 'business analysts' aren't smart enough but the way they perceive programming logic with computers is incompatible ~ http://www.cs.mdx.ac.uk/research/PhDArea/saeed/
Just because it has not worked until now, does not mean we stop trying. Unless there is proof of impossibility, we should try new attacks. In fact, languages have been getting more and more high level, so we are getting there, albeit slowly. If 4GLs, Case and MDA jumped the gun, that is another story entirely.
"... Just because it [BA's replace programmers - my addition] has not worked until now, does not mean we stop trying. Unless there is proof of impossibility, we should try new attacks ..."
Alexandros I'm in agreement with you because there are many instances of inventions where they displace on-mass specialised knowledge or skill. The tools & understanding we have to tackle the problem are too crude.
Can we create a counter-meme, "Eliminate Non-Programmers." Doesn't it seem like we're entering a world where small software and web business be run profitably by small teams of programmers?
No. There's nothing inherently special about programmers or the current crop of small software and web businesses that makes them any better at business than founders and startups in other industries except that they're still small. To scale a business still requires people with talents in marketing, sales, accounting, etc, etc.
Small businesses in almost every industry are almost always started by people with technical expertise in that industry. Whether the small business succeeds may be due to technical prowess to a degree, but whether it scales is largely due to the business savvy of the leadership, not their technical prowess.
In the same way, to the extent that small web businesses turn into large web businesses, it's due more to the leadership and business skills of the founders and management than how good they are at writing code.
I see something very special--the cost of starting a software business and the opportunity for getting it to profitability have become easier and more profitable for small teams of engineers. It's special because not all technical fields share these characteristics and it's special because it's newly prominent in web software.
I think it's fair, if we're measuring success in terms of money, to measure the success of a business by how big it gets. However, it seems completely wrong to then measure the success of individual engineers by the size of their business. Instead, you should measure their individual financial outcome.
The question that matters here is which approach maximizes the financial outcome for a programmer. Did the Trott's do the right thing for their family by taking funding for Six Apart, or could they have done more for themselves keeping it private? What about programmers that have a product idea that doesn't qualify for funding or wouldn't make good founders for a company with a traditional mix of talents? Would they do better joining such a company? Or building a company that plays to their strengths.
FWIW, my calculus on engineer-centric small business was around happiness and maximizing the time I spent building software that mattered to me.
A programmer's editor talking about how important programming is?
And it being rated up high on Hacker News?
Wow, who would've seen that coming!
I donno about the rest of y'all, but I'm a little tired of this self-serving "programmers are special" crap. IMHO there's a thick grey barrier between programmer and user, which gets thinner every day.
Especially in the newer generations of users, who are far more accustomed to the ways that computers operate. Let's be honest: 75-90% of programmers use terrible languages to write terrible software -- internal applications in vendor-supplied crap languages. They're not special, they understand little more than a few complex if/then/else blocks, and they're the vast majority of programmers.
We can argue that the upper crust of programmers are truly special, but if we could get rid of the garbage they had to interface with, I suspect their code could replace most of their own work as well.
Let's be honest: 75-90% of programmers use terrible languages to write terrible software -- internal applications in vendor-supplied crap languages. They're not special, they understand little more than a few complex if/then/else blocks, and they're the vast majority of programmers. </quote>
Reminds me of the DBAs complaining that the programmers have no idea how to construct a database. Anyone can create an X, but only Xers can do it well. You are always going to get better results from people dedicated to the particular problem domain, but in certain situations and with certain tools the extra quality might not be necessary.
Total elimination is not plausible, but de-skilling certainly is. It is already happening.
Anywhere a technique becomes standardised, reuse then simplifies programming. For example: relational databases -- developers don't have to create data storage systems anymore (mostly), they just use what exists. And there are many other similar pieces all over, especially with the rise of the net and web and open-source.
But one of the results is probably growth in usage, and that would then increase the need for developers, of all levels. So perhaps de-skilling, as a means to reduce need for programmers, won't actually work.
Even if we accept that it is a worthy goal to eliminate the need for programmers, I don’t think it’s possible. That’s because programmers have skills and abilities other than just their knowledge of programming languages.
Then shouldn't the goal be to create an environment with those skills and abilities built-in instead of worrying about what to eliminate?
