Programming made easy

Arseni Mourzenko
Founder and lead developer
161
articles
November 6, 2014
Tags: hiring 14

Peo­ple say, pro­gram­mers won't be need­ed one day

When I start­ed pro­gram­ming, a few peo­ple around me told me that this may not be the smartest ca­reer path, be­cause it may hap­pen that in a few decades, we won't need pro­gram­mers any longer. The idea is that soon­er or lat­er, de­vel­op­ment will be easy enough that any or­di­nary per­son would be able to build ap­pli­ca­tions and it will mag­i­cal­ly work. The idea is sup­port­ed by ads of code gen­er­a­tion tools and by the fact that an ap­pli­ca­tion which re­quired a decade ago a team of ten ex­pe­ri­enced de­vel­op­ers work­ing for six months can now be achieved by a young dude who spent the last week learn­ing PHP. The sim­plic­i­ty, a key fea­ture of any ad­ver­tised tech­nol­o­gy, stack, frame­work or pro­gram­ming lan­guage, cou­pled with sto­ries of guys who built an­oth­er mul­ti-bil­lion start­up in a few weeks makes the idea look le­git­i­mate.

But it has a flaw. Any or­di­nary per­son would be able to build ap­pli­ca­tions. Right. But a pro­gram­mer is a per­son who writes com­put­er soft­ware, so there is no such a thing as a di­choto­my be­tween pro­gram­mers and or­di­nary per­sons: if you write soft­ware, you're a pro­gram­mer.

OK, let's rephrase the thing. Any non-pro­fes­sion­al pro­gram­mer would be able to build ap­pli­ca­tions. Right. Like we nev­er had self-pro­claimed PHP pro­gram­mers who are as pro­fes­sion­al at what they are do­ing as I am at brain surgery.

Any per­son can cre­ate small pro­grams with­out learn­ing too much stuff. Too much stuff is am­bigu­ous, but I sim­ply can't be more pre­cise. You don't have to spend years learn­ing pro­gram­ming, but you do have to learn at least some­thing to cre­ate a use­ful pro­gram which works, giv­en that even this small amount of things to learn would be over­whelm­ing to most peo­ple (ac­tu­al­ly, most peo­ple can't even learn how to use a word proces­sor or a graph­i­cal ed­i­tor).

This leads us to the no­tion of bar­ri­ers to en­try. For ex­am­ple, to be­come a brain sur­geon, bar­ri­ers to en­try are high. One have to spend more than ten years in col­lege and suc­ceed. This is a huge in­vest­ment, there is a large amount of things to learn, and one should prac­tice a lot be­fore be­ing able to per­form his first surgery. To be­come a pro­gram­mer, or more pre­cise­ly to write at least one use­ful pro­gram which works, one should just spend a few weeks learn­ing stuff on­line. No need to buy ex­pen­sive soft­ware or even books. No need to pass any exam.

Were bar­ri­ers to en­try more com­pli­cat­ed in the past? They were be­fore in­ter­net and in­ex­pen­sive com­put­ing pow­er. To­day, those bar­ri­ers can hard­ly be low­ered any longer.

What about code gen­er­a­tion tools and new tech­nolo­gies, stacks, frame­works and pro­gram­ming lan­guages which will mag­i­cal­ly solve every prob­lem I have?

Code gen­er­a­tion tools are over­rat­ed and it looks like peo­ple work­ing on them tend to be some­times very op­ti­mistic. Code gen­er­a­tion works fine for sim­ple cas­es where a ma­chine out­per­forms an hu­man:

Aside ba­sic cas­es, code gen­er­a­tion is use­less. Some peo­ple would imag­ine that one day, code gen­er­a­tion will be able to cre­ate high­ly op­ti­mized code from a bunch of UML di­a­grams (they'll even quote an app which is al­ready do­ing it). There's none, and it's un­like­ly one will ex­ist, be­cause com­put­ers are not smart.

Aside, there is one cru­cial point: the best way to com­mu­ni­cate in­ten­tion. When it comes to con­trols in a win­dow, graph­i­cal tool is the best way to com­mu­ni­cate that this but­ton is large and is po­si­tioned here, while that one is small and is just in this cor­ner, but not too close to the bor­der. This makes code gen­er­a­tion use­ful here. On the oth­er hand, pro­gram­ming log­ic it­self is eas­i­ly ex­pressed through code, and it looks like no oth­er com­mu­ni­ca­tion medi­um could out­per­form it. This is the main rea­son why code gen­er­a­tion fails for or­di­nary pro­gram­ming log­ic: if there is a way to have the same flex­i­bil­i­ty when us­ing di­a­grams, it would be sim­pler to write code than to ex­press the thing through di­a­grams.

Take Mi­crosoft's Work­flow Foun­da­tion. It's help­ful when you need to as­sem­ble dif­fer­ent blocks to solve a ba­sic prob­lem, while mak­ing it pos­si­ble to change the work­flow lat­er dur­ing run­time. Now imag­ine a medi­um-scale ap­pli­ca­tion cre­at­ed with only work­flows; how would that look like? Ac­tu­al­ly, even a more ba­sic ex­am­ple is quite il­lus­tra­tive: what's eas­i­er, to write an if state­ment in code, or to do it with a di­a­gram? Ac­tu­al­ly, maybe an ex­pe­ri­enced de­vel­op­er won't even use an if, but in­her­i­tance; when you work with a graph­i­cal work­flow, you're pret­ty stuck with an if.

Now, ad­ver­tis­ers tell us that with their new thing, any­one will be able to cre­ate a ful­ly-fea­tured prod­uct in no time with no pro­gram­ming ex­pe­ri­ence need­ed. Great ex­am­ple: Mi­crosoft Piv­ot. In­deed, you end up cre­at­ing a work­ing web­site in a few min­utes with no code what­so­ev­er. But, wait, guys from Mi­crosoft nev­er told that you can cre­ate only one sort of web­sites, and that when your cus­tomer asks for a fea­ture that doesn't ex­ist in Piv­ot, you're back to code.

Pro­gram­mers be­lieve that too

The same idea that time will make de­vel­op­ers un­nec­es­sary, I heard it again and again dur­ing my ca­reer from my col­leagues, es­pe­cial­ly the old­er ones. They base it on the ob­ser­va­tion that a set of el­e­ments make it eas­i­er to de­vel­op soft­ware over time. Those el­e­ments in­clude:

Does all this make de­vel­op­ment eas­i­er? It de­pends.