Archive for the ‘CodeCompany’ Category

If It Quacks Hard, It Must Be

1 Comment »

Alan was complimented for completing his project on schedule. His supervisor looked over the program. With a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program however; it seemed quite incomprehensible. He realized by now that the project was really much more complex than he had originally assumed, and he congratulated Alan again on his achievement. (N.W. Rickert) [The Parable of the two Programmers]
If you can spot the logic error you are at the forefront of evolution, count yourself lucky. If your boss can spot the logic error count your self luckier and if they can’t, quit.

Only Your Opinion

No Comments »

WTFBWA friend of mine once worked on some code with a number of other people. At some point he found a large chunk of code that was unreachable, yet someone was working on it. After some inquires about the nature of the code, the person working on it got quite hostile, claiming the code was crucial and was in fact reachable. At some point a manager intervened. This manager listened to both parties and sumed up the problem. “So you claim the code will never be executed and you claim the code is crucial.” Both, my friend the coder and the other person agreed. Without much further thought, the manager decided that the other person should keep working on their code, claiming: “This is really a no-brainer. Since you both did not list any negative performance consequences, we don’t change anything.” When my friend emphasized again that the code was unreachable he was met with “But that is only your opinion.”

Control Is The Ultimate Illusion

No Comments »

peoplewareTom DeMarco has turned 180o, finally! As one of the initiators and most prolific proponents, if not principle responsibles of the software engineering myth, he finally sees his erring ways. After selling a fuckton of books on software-engineering like “Peopleware,” “Deadline,” “Controlling Software Projects,” and “Waltzing with Bears.” he now, finally, takes his distance. A bit late after 40 years, but I guess, the money was too good. He, at long last, acknowledges the folly of his most famous quote: “You can’t control what you can’t measure.” Never came so much stress to so many coders from so few words. Pity he does not apologize profoundly, but still it is good that he basically tells the world he has been wrong and misinterpreted. Finally he acknowledges, what all real-life-coders knew all along, the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value. (Tom DeMarco) [Software Engineering: An Idea Whose Time Has Come and Gone?] It is ending the era of the software engineering myth. It has hit the community hard, just look at a few reactions: CH, iTwire, Stackoverflow, Software Architecture, Never In Doubt.

Disgrunted IT Employees Everywhere

1 Comment »

In 2007, about 12% of the IT employees fit in category of “highly engaged” workers, but that has since fallen to 4%. “These […] most critical employees,” […] [are] 2.5 times more likely than the average employee to be looking for new opportunities. […] “The folks at Apple Computer […] are unlikly to be looking elsewhere. […] Employees elsewhere “are going to be shopping for […] purposefulness,” […] A Dice survey of 360 people in August found that over a third were planning to change jobs once the job market improves. (Patrick Thibodeau) [Surveys: IT job satisfaction plummets to all-time low]

So what is the point? Go else where or stay because it is no fun else where either? Or is it, maybe, change jobs often?

To Win Before You Code

No Comments »

avb1I know several über coders that would start a private printer server with: gcc -xc -;./a.out&, type for 90 seconds and their server would be up and running. I like them, the are generally fun people. I would never hire them though. It’s like having your car gassed up for free and find out they welded the gas tank shut. avb2 I would hire the kind that would think and than write (or download) some code and refactor it until it was solid. That is like having your car gassed up for half price and find out your car now runs a 100 miles to the gallon. Or maybe I would not hire anyone by the hour, but simply use something like ”Programmers are most effective when they avoid writing code. […] The romantic image of an über-programmer is someone who fires up Emacs [or IYFEH], types like a machine gun, and delivers a flawless final product from scratch. a A more accurate image would be someone who stares quietly into space for a few minutes and then says ‘Hmm. I think I’ve seen something like this before’ (John D. Cook) [Why programmers are not paid in proportion to their productivity]. Managers love to reward according to measure. But code productivity is hard, if not impossible, to measure. If team productivity is hard to figure out, it’s even harder to measure the contribution of individuals on that team. You can get a rough sense of a team’s output by looking at how many features they deliver per iteration. b It’s a crude sense, but you can get a sense of whether a team’s speeding up, or a rough sense if one team is more productive than another. But individual contributions are much harder to assess. While some people may be responsible for implementing features, others may play a supporting role – helping others to implement their features. Their contribution is that they are raising the whole team’s productivity – but it’s very hard to get a sense of their individual output unless you are a developer on that team (Martin Fowler) [Cannot Measure Productivity].

Choosing a Language

No Comments »

Managers often are confronted with a need to choose a programing language. Usually they ask themselves questions like: “How simple is it to learn language X?”, “Do our coders like to switch to language X?”, “How well does our IDE support language X?”, “How well known is language X?”

These questions, however, might not be all that relevant. While a Turing Machine can be used to code graphic animations, probably a more abstract and domain specific language like Processing would be more productive (and fun). However a Turing Machine might score better on the questions above. The more relevant questions for selecting a language focus on two terms domain and abstraction. I won’t try to explain why, or even define these two terms (click the link, Luke). Suffice it to state that: Experienced coders use more abstract features to make more compact code and, thus, be more productive. Domain specialists use more domain specific features to code quicker and, thus, be more productive.

One could be forgiven the mistake of thinking that the more abstract a language is the less domain specific, and vice versa. A random counter example is PostScript, a powerful, abstract, concatenative language, used almost exclusively in the domain of printers.

So if you employ a domain specialist (count your blessings and) choose a domain specific language. If you employ a code wizard (count your blessings and) choose an abstract language. About the worst you can do, is pick a abstract, general-purpose, multi-paradigm language like Python for a mathematician to code math models. Best case this will eventually lead to a huge and clunky library stack like Python(x,y), that dictates every other aspect of all the code that interfaces with it. Very soon, the lack of flexibility will drive everybody back to using a spreadsheet for their modeling. Maybe a better choice would be a language like R, or indeed that spreadsheet.

Breaking Software Development

No Comments »

Why are programmers so fussy about their employers’ morals? Partly because they can afford to be. The best programmers can work wherever they want. They don’t have to work for a company they have qualms about. […] And it’s not fun for a smart person to work in a place where the best ideas aren’t the ones that win. (Paul Graham) [Apple’s Mistake] True that. If you want the best programmers, be the place they want to be at hardest. If you want the smartest programmers, don’t give them a manager that want’s to win, give them one that wants to serve. [via: DI]

Long Matters Short

No Comments »

Banks play a pivotal role in the finance system, they perform a kind of miracle, they make short money long. Come to think of it, most companies, not just banks, perform such miracles. Companies, make long visions short. Management takes the long term goals of a company and by ways of a miracle translates them into short term goals for the people that actually do the work. So, wonder no more, that is what management is good for … in theory. In practice management often emits quick and dirty shorts that do not sum into coherent longs. With most tech-companies, this is even more difficult to spot because a manager, feeling the lack of effort behind their decision, will effort-up the decision by trying to express it in quasi tech-terms.

So next time, you go WTF? Just ask them two things. First, why are you telling me how-to-do instead of what-to-do? And second, what long term goal does this serve?

Vorm en Kleur

No Comments »

“When I was a young boy” (Muddy Waters) [Manish Boy] my mother done told me, I was one scary boy. Mind we are talking pre PC era. Actually the IBM PC was still ten years a-coming. Yes, we are talking August 1971. I was at the age of five—just. Somehow I had gotten hold of my sisters “vorm en kleur” (shape and color) booklet. (I summoned all my google fue, but to no avail, so I can not show it to you here.) It was some typical ’70s teaching tool. vorm (shape) There were colored shapes, like red-squares, or blue-triangles. There, also, were “boxes” that would interact with the colored shapes, either changing a shape or a color. E.g., from square to triangle, or from red to green. kleur (color) I instantly absorbed the booklet and soon I was filling paper after paper with my own variations. I had generators, that produced a specific shape and color, no matter what the input was. I noticed that boxes could not handle all input draai-kleur (color-rotate) (i.e., the domain was limited), so I made up rules, like door-als-past-niet (pass-if-unfit) and designed draai-vorm (shape-rotator) boxes that would work for any shape and draai-kleur (color-rotate) that would work for any color. I would string boxes into more complex boxes. kies-pas (choose-fitting) I would draw boxes with multiple outputs, multiple inputs, an arbitrary input symbol (actually a question mark), kies-maar (choose-arbitrary, i.e., a non-deterministic box), kies-pas (choose-fitting, i.e., box overloading), duplicator boxes, switcher boxes, decider boxes (i.e., flow control), state-holder boxes and many others. The shear volume of papers littering my room, with all these boxes, really scared my mother—or it might have been my unwillingness to interrupt my journey for trivial mundane thins like eating, sleeping, social interaction and personal hygiene. Basically, that was when I learned all there was to know about input, process, output. Everything I learned about writing code later in life seemed a trivial continuation of “vorm en kleur.” And why am I laying this funky bit on you? Well, the original “vorm en kleur” system—not including my extensions—probably is the most complex thing a non techie, will be able and willing to understand. So it might be the perfect tool to explain the biggest known secret of systems design: The inside matters. Ok, a raise of hands, who amongst you pro-programmers has had trouble in the past explaining this to some manager? Ok, ok, just what I thought. Next time explain “vorm en kleur” and draw them this:
what we haveTell them: “This is what we have. This is what we need.” and draw them:
what we need If they don’t understand, just quit, seriously, run while you still can. You know why? Because that would-be-colleague that writes those “what we have,” by virtue of delivering some results that the customer came to accept, will be put in charge of designing the grand new integrated product that will be the apotheosis of all your company’s products (all in Python, mind) and “they” are going to bet the whole company on you saving the day while crediting your ex-colleague-now-boss. You will die a slow and painful death. You will die from battle fatigue—or maybe it will be the lack of time for those trivial mundane thins like eating, sleeping, social interaction and personal hygiene. And you want to know the worst part of it? You are sure, you want to know the most gruesome part? You know, you know what the worst part is, already. Right? Worse than dying, your legacy will be a big pile of shitty code. So… run… run… run… like a man.

Bare Minimum Effort Loser

No Comments »

compLifeCycle“A sociopath-entrepreneur with an idea recruits just enough losers to kick off the cycle. As it grows it requires a clueless layer to turn it into a controlled reaction rather than a runaway explosion.”
“Sociopaths, in their own best interests, knowingly promote over-performing losers into [clueless] middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves.”
“Eventually, as value hits diminishing returns, both the sociopaths and losers make their exits, and the clueless start to dominate. Eventually, the hollow brittle shell collapses on itself…” (Venkatesh Rao) [The Gervais Principle]
If you are a good programmer, than you will be—by definition of the word: good programmer—perceived as “bare-minimum-effort” loser. It is the effort that counts. That is why you are left to fend for your self. So there, now you know.