RhodeCode

IBM is having another heart attack, HP is falling apart, and those crashing share prices are a dose of reality to those buy innovative companies and process them into a business unit shops. Now the bad ideas are getting shed and creative destruction continues in the marketplace. This darwinism is accelerated in software and technology because anybody with a computer can potentially wreck your business tomorrow morning. Your software becomes obsolete, your product antiquated, and your board members suddenly start a share buyback programme to support their stock options.

Read more…

The RhodeCode infographic charts how we got to where we are today. From Marcin’s initial idea to a rapidly growing software development company creating the world’s best software development solutions.

Read more…

Team work is not a skill, it is a philosophy that you develop and it becomes part of who you become. Depending on how you decide to bring your team player mentality to work, you will either be a great benefit to your colleagues, engendering a situation where both you and others can perform to their best and create a positive and productive work place, or you will be a myopic, probably narcissistic, ego-centric person lacking the self-awareness to make a positive difference. You are on this imaginary scale of extremes, every single day, if you work with other people.

Read more…

This week I cover for the third and final time - code review. The direction of this weeks blog comes from our very own coder supreme Sebastian Kreft who pointed me in the direction of a case study done on NASA best practices used to develop the code that landed the Curiosity Rover on Mars.

Read more…

Last weeks blog covered code review, how it makes your programming better, your products more stable, and accelerates your learning. But all that is a little wishy washy when facing a skeptic focussed on numbers and who wants to know why it's not full steam ahead. This excel sheet mentality tends to run headlong into the bigger picture vision and steamrolls right over it with it's reliance on numbers, however subjective the measurement criteria might be. In the world of business numbers triumph over logic every time. Writing 1,200 lines of code this week looks better on paper than 800 lines of code. But, done right, 800 lines of code may be 150% better, more stable, and more secure than the 1,200 lines.

But, how do you put quantifiable numbers behind your argument, and build a strong case for using a code review process in your development environment?

Read more…