Ignore Tools, Infrastructure, and Process To “Maintain” Team’s Productivity

If you’re running and you’re followed
By some forty angry people –
Try to work it out quickly:
What’s upsetting them so much?

You must listen to everybody,
Give a piece of good advice.
But it’s strongly recommended
That you keep an even speed.

— Grigory Oster, “Bad Advice”

It’s year 2016 and your team is developing an application, a service, or other kind of software project. Here’s an incomplete list of suggestions which help the team to keep productivity where it is now.

You can use it as a checklist for now, but feel free to extend the list with ideas that make more sense in your organization.

Code Management and Code Confidence

  • DON’T use distributed source control systems, e.g. Git, Mercurial.
    These tools have a very steep learning curve. Only hackers, geeks, and kids can waste their time on such toys. True professionals don’t need Git to make a project successful!
  • DON’T have any sort of code review practices.
    Weak developers in the team can learn from the code written by the strong ones; while the strong developers never make mistakes.
  • DON’T write unit tests.
    Making sure your class is working as expected is not helpful for testing the entire system. If the correctness can not be checked, why bother at all, right? Once you write a test, the entire team will struggle maintaining it. No good.
  • DON’T write integration tests.
    Integration tests are slow, fragile, and generally unreliable. Running these tests regularly may block a developer for long time periods — when does he write code then?!

Building and Deployment

  • DON’T use continuous integration services.
    CI is hard to configure. Once in place, it will keep bugging team about errors which can be resolved later. Team needs to be focused on delivering features!
  • DON’T use staging environments (e.g. test → integration → preprod → production).
    Remember what I said about the maintenance? It’s not fun to keep deploying new versions of the code every day — this is a slow manual process (see previous point). You should have learnt by now how to detect and avoid the burdensome practices.

Code reuse

  • NEVER package your code into NuGet, Maven, npm, jspm, PyPI, RubyGems, etc.
    First, if somebody needs your code, they should ask you to get it. Even if this is somebody from your company. No exceptions!
    Second, why don’t they write the code themselves? You did not volunteer to help other departments with what they are doing, and if you give them a package they’ll keep asking you to fix the bugs which you can’t reproduce!
    Third, packaging code is an extra work. Instead, you can copy-and-paste it to other places when necessary.

Requirements and Quality

  • DO EVERYTHING YOU CAN to keep business analysts (or business owners) away from the developers.
    Everybody knows how good are these guys in interrupting the ‘working ants’. You don’t want to waste time explaining what are you working on — BAs will never understand anyway.
  • DO only what the functional specification tells you to do.
    The team should trust UX/UI designers. By revisiting the designers’ decisions you put yourself at risk of getting more work after all. Even if you build a system which is not very comfortable to work with, you can always refer to specs and blame others.
  • DON’T conduct demos with BAs!
    Every demo is the same. The developers proudly present their three months progress. The BAs only complain about pretty much everything. After several hours of struggle the stunning conclusion is declared: most of the stuff needs to be reworked. At the very best, the team ends up with a huge scope creep.
  • NEVER have internal demos.
    Team members’ morale and feelings are affected severely when the results of the work are being reviewed. You don’t want it to happen because when you eventually have a demo with BAs the team should be united in the face of the enemy!

Methodology, Religion, and Other Esoteric Stuff

  • DON’T fall into delusions of “Agile” methodology.
    Nobody needs to rework anything if it’s designed well from the beginning. NASA was able to build a space vessel that delivered an astronaut to the Moon without blowing hundreds of prototypes! Why do people think a team can’t design and code a working system that is by orders of magnitude simpler?
    Don’t trick yourself! Agile is a process hard to follow and you can barely fix it. Many teams have tried to adapt it and failed to deliver their projects on time!
  • DON’T “experiment” with new tools.
    There’s always plenty of hype about some “fancy” new things. Ignore it. Let the neophytes keep relearning how to write their Hello World app yet another way. Meanwhile, your team — a band of real professionals — can build a real system with the silver bullet languages and frameworks.

…to be continued

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s