Opened Registration for CTO Startup School Berlin

I’ve opened the Registration form for CTO Startup School Berlin. Booked out, adding a waiting list.

CTO Startup School Berlin, 5th of March

Because many people asked me privatly about technical startup questions, I thought about batching those up and organizing a workshop for technical startup questions. Booked out, adding a waiting list.

So there will be a CTO Startup School Berlin day on the 5th of March, from 9:00 to 18:00. The number of people is limited to 20, entry is free.

Agenda

1. Introduction (CTO role, company phases)
2. Development (Process, agile/lean, quality, project managment, estimation, introducing change, tools/setup)
3. Plattform (Programming languages, frameworks, storages, persistence, time to market, maintenance)
4. Operations (Deployments, releases, hosting, cloud, architecture, hardware, monitoring)
5. Scaling (models, costs, where/what/when)
6. Hiring (Outsourcing, process, headhunter, interview questions, telephone screening, layoffs)
7. Other (Portfolio management, innovation, KPIs/metrics, internal IT, backup, security, CD/DR)

There will be a registration site this week. If you miss something, leave a comment.

You’re a Bad Programmer, Really?

Jared Richardson wrote a post titled You’re a Bad Programmer. Embrace It.

How many developers think they’re good programmers? We’re not. We’re all fairly bad at what we do. We can’t remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we’ve spent years, in some cases decades, learning? We can’t even type the syntax properly, so we have compilers that check and correct it for us.

He argues in the post that we are all bad programmers, should embrace it and use tools to get things barely work this way. But is this really the case? Are we all bad programmers? From my experience there are good and bad programmers, and fewer good than bad ones. To claim all programmers are bad is stretching reality a lot though. There are good programmers everywhere. And they are not good because they use tools – I’d argue they are good and therefor use the right tools. I wrote more about good programmers in “As a Manager: What I value in developers”.

Beside the bold claim, the post is really thin on facts. One cited fact is the failure rate of software projects:

Don’t even get me started on the correctness of the logic in the code… I’m looking at a chart that shows failure rates for software projects. “Small” projects (about a year for 8 people) have a 46% success rate. That’s almost half. Any longer project just plummets down to a 2% rate for projects costing 10 million or more. In other words, our projects nearly always fail.

Following the logic, projects fail and therefor programmers are bad. Having worked in software development for over 15 years and developing software for nearly 30 years, my point of view is different. It’s not the fault of developers that projects fail. So this is not an argument for bad programmers. It’s the context and environment that make projects fail. Mostly project management in software development is done in a way no success can happen. Projects in our industry fail …

1. Mostly due to wrong estimation – estimation done not by the person who does the work package but by the project manager. Work packages are too large so no proper estimation can happen. I’d argue any work package (WP) larger than 1 to 3 days can not be easily estimated.
2. Mostly due to wrong status updates, like work packages which are 80% or 90% complete. This leads to a false sense of accomplishment and makes the project manager think he’s on track for a long time, until suddenly the project fails. Good project management only knows three states for work packages: Todo, In Progress, Done. Then project status is easily calculated: Number of done WP / Number of all WP.
3. Mostly due to wrong way of change management. Features are added all the time leading to scope creep. What works: Replacing WPs that are no longer needed with ones that are hot.

You’ve guessed it, Scrum adresses all of these resulting in 99% – 100% on target delivery. So it’s not due to bad programmers if an agile process can fix this.

The claims in the post get bolder and broader:

In short, as an industry, we all stink.

When we stink as an industry, programmers are the smallest part in it. The only part where programmers constantly fail is with maintanence, writing code that can be read an rewritten months or years from now.

The only solution according to Jared is using tools:

Once you’ve embraced this bitter reality, you can start to move forward. Once you’ve admitted to yourself that you’re a bad programmer, you can stop all the silly posturing and pretending that you’re great, and you can look around and find the best possible tools to help you look smarter than you are.

There is no bitter reality. There are good programmers, not all are bad. Embracing that you’re a bad programmer is the wrong direction. I wasn’t a good programmer when I’ve started 30 years ago. I could copy what I’ve seen others type into machines, making them print “Hello World” and flashing colors with POKEing numbers into memory cells. Constant struggle and the acceptance of programming as a craft made me better. You should not embrace that you’re bad, you should strive to always become a better programmer and embrace becoming the best. Good programmers use tools, from my experience, unit testsm static analysis, continous integration, bad ones don’t – they do not see the need and benefits of tool usage. Good programmers demand the introduction of tools. The basic assumption that bad programmers should use tools to become better is the wrong way around, good programmers use tools.

Final Point

There are good and bad programmers. The good one are those who want to become better, are interested in their craft, the bad ones are those who do 9 to 5 jobs without any interest in their profession.