I have come across an excellent article about Scrum: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Left-liberal totalitarism.

This is the text that got a software engineer fired: Google's ideological echo chamber

Google's Ideological Echo Chamber (pdf)

Is there any different between Communist Russia circa 1970 and today's Silicon Valley? I can't think of any.

Real "Pair Programming"

Looks like North Korea is leading in introducing Pair Programming to the Agile software development teams:

Code reviews

Some thoughts I have on how to organise code reviews when you are a team leader (at least this is what I try to follow):      

• Code changes need to be reviewed before merging it to Master branch and before testing.

• As a leader, code review all changes done by other people, but ensure that everybody else is involved in code reviews (others don't have to code review everything, but ensure that everybody does some code reviews).

• Ensure that your code is always code reviewed by your team members and always react positively when a problem is found with your code, make changes to the code you written based on advise of the junior team members. This will ensure that the team members don’t see a problem someone found in their code undermines their position.

• Don’t nitpick, accept that different people write code differently. Insist on modifications to the work you reviewing only in a case of a bug or if the change that does not fit with overall design. Be polite and try to explain the reason.

• Have coding standards and ensure that tools for automatic code formatting are used (in case of Java IDEs both Eclipse and IntelliJ allow this and you can copy formatting rules between computers — when someone joins the company, just send them the formatting setup file). This will prevent “formatting wars” and comments about formatting.

• Have static code analysis tools run as part of CI (e.g. Sonar), this will reduce disagreements — psychologically it is easier to accept criticism from a machine then from a fellow developer.

Joys of legacy code

I have recent stumbled across this text: http://typicalprogrammer.com/the-joys-of-maintenance-programming/

Somehow it resonated with me. I started working as a developer in early 1990s and I have done it all – “green field”, maintenance, you name it, I had my share of creating software from scratch, I had experience of re-architecting existing software and I experienced fixing bugs in code that was written before I learnt how to program in a language nobody wanted to learn anymore.

What I have noticed that as time goes I enjoy maintenance development more and more.

Often I find developing software from scratch to be too easy and boring. I find there is more challenge in making legacy code “great again”.

I can understand why those, who have never had a chance to do it, are dreaming of “green field development” and writing systems from scratch using latest and coolest technologies and methodologies. Many developers believe that if only they were given a chance, the software they will design will be much better then whatever they work with. Unfortunately, it is not the case…

I would say that the majority of developers are able to write a new application that will more or less do what is required. But in most cases, couple years down the line, their code will probably be found by “the next guy” to be even worse then the one they love to criticise. I think only a minority of programmers can actually make an old code with layers and layers of changes to be nice again.

Polyglot programming and micro-service architecture

Recently I was trying to understand how a micro-services based system was designed by looking at the source code. The code was developed more or less recently in a company for an application that provided web access for customers.

It was a service in Kotlin calling a service in Scala, which in turn was calling a service in Groovy, which was calling a service in Java…. At that point I lost the will to go any further.

On each step one needed to figure out which other service is called (this is not easy if you have a lot of different services and very limited documentation) and then to try to switch to a different language and a different frameworks with different conventions (e.g. where a controller to be found etc.).

Unfortunately I have a very strong suspicion that this madness is there to stay. The problem is that micro-service architecture gives developers a chance to write software from scratch (something many people, who have never done it before, would love to do and who usually do it awfully due to lack of previous experience) and it gives an excuse to learn a new programming language while been paid by the employer to do it.

Pair Programming – what’s in it for me?

There are many advocates of Pair Programming explaining why they think this way of organising software developers’ work is good for the company. But I have not seen much explanation why it might be good for a developer. We, developers, usually enjoy what we do and care enough for the success of the projects we work on, but I don’t think many of us would get up in the morning and commute to our place of work if there was something for us as well – we would like to be paid well and we like to have a career. This means that our choices are not defined by what good for the company but also what is good for us personally.

Pair Programming was around for quite some time (XP is here since 2000), but I have a feeling that recently I am hearing more about this then I heard before.

Interestingly I also have an impression that when hear about 100% pairing, it would normally be either involve an IT consultancy practising it or people who in the past used to work for one of IT consultancies.

I suspect there is a reason for IT consultancies to practise pair programming – you can charge for two people doing the same work (explaining that “it improves the quality”) and it would allow them to send to a customer an inexperienced developers paired with one that have experience while charging if they both were experienced.

I can also understand why managers might like it – it allows them to see developers as an exchangeable “resource”, eliminating a “bus factor” while at the same time ensuring that the developers police each other in terms of actually “doing the job” and having even to inform each other when they go for a pee.

What I don’t understand is why some developers support this?

Do people really want to be sitting next to someone else at the same desk day in and day out instead of having their own place in the office, which they can personalise the way they like (pictures of kittens, Star Wars poster or whatever else their personal kink would be). Don’t they want a place where they don’t have to suffer because someone else has poor hygiene habits?

Do they want to be able to use any IDE they fancy and setup their machine to whatever weird configuration they favour, or do they prefer this decided by a “committee” and they been forced to follow rules?

Do they like to be “one of the pair” instead of “that guy who did that cool thing”? Are they feeling too insecure in their professional abilities that they are afraid to work on their own?

How do they see themselves in 10 years time? Still be a faceless member of a “Team” members of which are not even trusted to work on their own at their own desks?

Talking about personal interest as far as a developer concern I can see only disadvantages:

-       It is more difficult to demonstrate your own abilities and worth to the management if they never see your name attached to anything unless it is with other person, hence less chances of career advancement based on your own abilities as a programmer.

-       The management sees you as replaceable (as far as they concern there are always other people available to do your job, everybody you are pairing with are good enough candidates).

-       You have less freedom over what you do and how you do it – you have to explain every step to your pair and you have to coordinate with others all your activities

-       You have less comfort in your workplace, as you have to share space in front of the screen with someone else.

Other people's blog posts on Pair Programming:
I'm a Pair-programming Skeptic
Why I Don't Like Pair Programming (and Why I Left Pivotal)
https://www.infoq.com/articles/pair-programming-no-panacea

Posted copy on Dzone: https://dzone.com/articles/pair-programming-whats-in-it-for-me