Articles tagged “quality”

• Quality and practice: convincing as a consultant When you act as a con­sul­tant in a com­pa­ny, the first thing you must re­mem­ber is that you're not the per­son who takes the de­ci­sions. While you might be the source of in­fi­nite wis­dom, peo­ple will lis­ten to you, or they will not. When your voice is not…
  communication 27 quality 36
• Quantifying time and cost: why do we always get it wrong? Dis­cus­sions like this hap­pen all the time when you work in IT. You are giv­en a sum­ma­ry which bare­ly de­scribe the pro­ject, you have no time think­ing about it, and then you re­ceive a strong pres­sure from your boss be­cause some PHP code mon­key from a…
  communication 27 quality 36 management 34
• Ascending and descending representations of quality There are many pro­jects which start with very low ex­pec­ta­tions of the qual­i­ty of the source code and pro­ject or­ga­ni­za­tion. The idea is to get some­thing which sim­ply works, start to sell it, and then, ei­ther con­tin­u­ous­ly or in one bru­tal step,…
  management 34 quality 36 short 50
• Closed source, secrecy and trust Most com­pa­nies which pro­duce source code don't re­lease it in the wild. They are hid­ing it, pro­tect­ing it against unau­tho­rized ac­cess, ob­fus­cate it, make you sign NDA and ask them­selves how they can be sure that the code will nev­er ever reach…
  quality 36 rant 34
• Don't ask writing good code What a sur­prise. Af­ter be­ing asked for months to sim­ply write code as fast as pos­si­ble, with no think­ing or test­ing, man­age­ment sud­den­ly crit­i­cized one of the col­leagues, be­cause the code of a new, un­sta­ble fea­ture im­ple­ment­ed to­day con­tains long…
  management 34 quality 36 short 50
• Comments classification This is a bad com­ment: int i = 0; i + 1; // adding 1 to i should work but dont work i dont know why!!!! print(i);For every good com­ment, I've seen hun­dreds of bad com­ments. They harm the code base and give the wrong im­pres­sion to the au­thor that he…
  quality 36 refactoring 12 featured 8
• Dunning–Kruger effect Dun­ning–Kruger ef­fect con­sists for un­skilled per­sons to be­lieve that they are more ex­pe­ri­enced, and for high­ly skilled per­sons to un­der­es­ti­mate their lev­el, be­liev­ing that tasks, which they find easy,…
  hiring 15 quality 36
• Linters rock, but they are slow I love lin­ters. I love them so much that I'm ac­tu­al­ly con­sid­er­ing to use some of them at pre-com­mit stage to re­ject com­mits which con­tain er­rors. The only thing which is the rea­son I hes­i­tate to do it is that some of them are quite slow. Cur­rent­ly,…
  code-style 3 quality 36 productivity 36
• Measurements as a precursor of culture of quality When au­dit­ing dif­fer­ent IT com­pa­nies, the no­tice­able pat­tern is that com­pa­nies which per­form bad­ly have prob­lems in every imag­in­able area. I've nev­er seen a com­pa­ny which has out­stand­ing work qual­i­ty…
  productivity 36 management 34 quality 36 workplace 7
• Micro-services in a context of high complexity and low code quality One of the most prob­lem­at­ic things of a soft­ware de­vel­op­er is how to han­dle the in­creas­ing com­plex­i­ty of a giv­en code base and the de­creas­ing qual­i­ty of it. Code which, when orig­i­nal­ly writ­ten, was read­able and un­der­stand­able, looks com­plete­ly scary…
  short 50 productivity 36 quality 36 refactoring 12
• Topography of tests Im­por­tant note: this ar­ti­cle is writ­ten for de­vel­op­ers who don't prac­tice TDD, that is more than 99% of de­vel­op­ers I know. TDD is a very dif­fer­ent world, and a few as­ser­tions I make in this ar­ti­cle don't ap­ply there. For in­stance, my skep­ti­cism…
  testing 7 productivity 36 quality 36 featured 8
• Should students be using syntax highlighting? A few months ago, some­one asked a ques­tion on Stack­Ex­change, won­der­ing if there is a re­search pa­per in­di­cat­ing whether syn­tax high­light­ing helps or slows down the learn­ing process of fu­ture pro­gram­mers. The ques­tion was closed and delet­ed, so here…
  short 50 quality 36
• Linters and style checkers: how to save hours of painful debugging I'm al­ways im­pressed with the con­sis­ten­cy of screw-ups caused by the un­will­ing­ness of pro­gram­mers to fol­low ba­sic guide­lines. To be more spe­cif­ic, I'm talk­ing about my own screw-ups here. I've been con­vinced a long time ago that: Style check­ers and…
  productivity 36 short 50 quality 36
• Measurement: a two-edged sword Too of­ten, the prac­tice of mea­sur­ing things is used in place of ba­sic think­ing, and, log­i­cal­ly, leads to low cus­tomer sat­is­fac­tion and poor prod­uct qual­i­ty. The ma­jor rea­son for that is that in most cas­es, mea­sure­ment is de­hu­man­iz­ing. A cus­tomer,…
  short 50 performance 13 quality 36 rant 34
• Do we think enough about coding standards we use? What is wrong about cod­ing stan­dards and “best prac­tices” in gen­er­al is that they throw the think­ing process away. This may be a good idea for man­u­al work­ers, but is quite prob­lem­at­ic for de­vel­op­ers.…
  quality 36 code-style 3
• Telecommuting and procrastination My col­leagues and I had re­cent­ly an in­ter­est­ing dis­cus­sion about let­ting de­vel­op­ers to work at home. They high­light­ed that one of the is­sues of telecom­mut­ing is that it makes it dif­fi­cult for the…
  productivity 36 management 34 quality 36
• Person-centered metrics and self-organizing teams We can­not re­li­ably mea­sure de­vel­op­ers' pro­duc­tiv­i­ty, and this is the ma­jor el­e­ments which push­es many man­agers to fo­cus on less rep­re­sen­ta­tive as­pects of de­vel­op­ers' con­tri­bu­tion to a pro­ject and a com­pa­ny. Some com­pa­nies do a re­al­ly bad job,…
  management 34 quality 36 productivity 36
• Interfaces in microservices Ob­serv­ing large in-house sys­tems which ei­ther use SOA ap­proach­es or even at­tempt to mim­ic mi­croser­vices, I con­stant­ly no­tice a pat­tern which makes those sys­tems sub-op­ti­mal and dif­fi­cult to main­tain. A tiny Hel­lo World-style ap­pli­ca­tion can eas­i­ly…
  productivity 36 quality 36 microservices 2
• Those things we measure A re­cent change in Book­shelf ser­vice re­moved the counter which in­di­cat­ed how many books were dis­played on the page. To be more pre­cise, the counter can only be vis­i­ble by the user in per­son, but not pub­licly. This is es­sen­tial­ly a shift to sub­stance…
  quality 36
• Don't ask writing quality code Four years ago, I com­plained about peo­ple who are ask­ing to write good code in a con­text where the com­pa­ny cul­ture it­self leads to bad code in the first place. I ex­plained the ne­ces­si­ty of RCA, and the use­less­ness of in­di­vid­ual sug­ges­tions to write…
  quality 36 workplace 7
• What makes performance decrease over time? In an ex­cel­lent blog post, Niki­ta Prokopov shares his thoughts about “our in­dus­try’s lack of care for ef­fi­cien­cy, sim­plic­i­ty, and ex­cel­lence,” ex­plain­ing, among oth­ers, that year af­ter year, hard­ware be­comes more and more pow­er­ful, but ap­pli­ca­tions…
  performance 13 quality 36 profiling 4
• Take risks, fail fast In many soft­ware de­vel­op­ment teams, the source code is sa­cred. Its sa­cred­ness is caused by two fac­tors: The code is the ul­ti­mate ex­pres­sion of the in­tel­lec­tu­al work of the de­vel­op­ers. If you have any­thing against the code, it means that you're…
  productivity 36 quality 36 refactoring 12 rant 34 requirements 3
• Monochrome laziness Twelve years ago, Win­dows Vista was re­leased, im­press­ing every­one by its shiny, elab­o­rate icons. For in­stance, a re­cy­cle bin was il­lus­trat­ed by a shiny trans­par­ent waste bas­ket. Search func­tion­al­i­ty was shown in a form of a metal­lic mag­ni­fy­ing glass.…
  rant 34 design 2 interaction-design 9 user-experience 10 quality 36
• Lazy programmer fallacy There is, among pro­ject man­agers, a think­ing that pro­gram­mers are lazy. Pro­gram­mers—they say—don't want to work; they pre­fer play­ing games or just do­ing noth­ing at all. This is all but truth. Ac­tu­al­ly, many pro­gram­mers en­joy pro­gram­ming. They have…
  rant 34 short 50 management 34 quality 36
• YAGNI principle in action Dis­cussing YAG­NI with col­leagues, I of­ten find my­self in a sit­u­a­tion where they give me a con­crete ex­am­ple where they were very hap­py to think about a giv­en fea­ture or as­pect be­fore it was re­al­ly need­ed. As those dis­cus­sions al­ways fol­low the same…
  rant 34 productivity 36 quality 36 refactoring 12 agile 10
• Workflows, ETLs, and pure magic Five years ago, I wrote a rather opin­ion­at­ed and very crit­i­cal ar­ti­cle about Nin­tex Work­flows, a per­fect­ly use­less prod­uct which makes your life mis­er­able while you're pay­ing for it. Nin­tex is sold as a so­lu­tion to al­low non-tech­ni­cal per­sons to…
  quality 36 productivity 36 python 5
• Measuring quality and undesired behavior When I talk about mea­sur­ing qual­i­ty, I can't em­pha­size more how mea­sur­ing a giv­en thing in­flu­ences the be­hav­ior of the per­sons who are be­ing mea­sured. When done prop­er­ly, this is an ex­cel­lent lever which en­cour­ages per­sons to work bet­ter. In oth­er…
  quality 36
• Measuring quality like a pro My pre­vi­ous ar­ti­cle led some of the read­ers won­der­ing how a cor­rect ap­proach to mea­sur­ing stuff looks. I'll use this as an op­por­tu­ni­ty to show how I worked my­self as a con­sul­tant. The ar­ti­cle would…
  quality 36
• How to deadlock a project In 2014, I wrote the ar­ti­cle Tak­ing hostages with Wa­ter­fall, ex­plain­ing how Ag­ile moves the pow­er of de­ci­sion about the scope and the cost of the pro­ject from the ones who make the soft­ware to the…
  blog-engine 2 management 34 quality 36
• When testing is not fun enough On reg­u­lar ba­sis, some col­league starts com­plain­ing in an in­for­mal dis­cus­sion about the low qual­i­ty of some pro­ject he's work­ing on. It has to do with code qual­i­ty, or lack of tests, or both. Every…
  testing 7 quality 36 rant 34 productivity 36
• Languages usage over time I start­ed pro­gram­ming a long, long time ago. The old­est source code I can find in the archives is from 2004. Back then, I was sev­en­teen years old, us­ing Vi­su­al Ba­sic and some­thing that I be­lieved…
  productivity 36 quality 36
• Using LOCs to validate hypotheses In my pre­vi­ous ar­ti­cle, I was talk­ing about the tool which gath­ers the diffs from the ver­sion con­trol com­mits, and uses them to com­pute the num­ber of lines of code (LOC) per lan­guage over time, in…
  productivity 36 quality 36
• Designing documentation and technical emails A few years ago, I was work­ing on a pro­ject where a part was done by a team in Lon­don, and the oth­er part was de­vel­oped in France. To com­mu­ni­cate, we were us­ing among oth­ers the Web­Hooks, for the sole…
  visual-design 1 information-design 1 communication 27 quality 36
• This is what you get when you measure lines of code A few months ago, I wrote an ar­ti­cle about a tech­ni­cal leader who mis­un­der­stood how to mea­sure code qual­i­ty. Try­ing to im­prove things, his only achieve­ment was to make every­thing worse, be­cause of the…
  short 50 quality 36 javascript 3
• What targetting 100% code coverage taught me I was re­cent­ly in charge of draft­ing a new sys­tem for a cus­tomer. I took it as an op­por­tu­ni­ty to demon­strate some of the ap­proach­es that should lead to high­er qual­i­ty soft­ware, com­pared to what the…
  testing 7 unit-testing 6 quality 36
• Edge cases Soft­ware prod­ucts are de­signed for the cas­es where things go right, the sit­u­a­tions, where net­works are per­fect­ly flaw­less, servers don't re­boot ran­dom­ly, and process­es hap­pen as they would hap­pen in…
  quality 36 management 34 interaction-design 9 user-experience 10