18 July 2016

Hosting Public Coderetreats

I described the needs and benefits of inhouse Coderetreats in the previous article. (In case you did not read it - a Coderetreat is a full day hands-on coding workshop focused on the fundamentals of software development and software design. It is a day full of fun and excitement.) In this second part about Coderetreats I will say more about the opposite of (buying) an inhouse event, which is (hosting) a public one.

Hosting a public Coderetreat is obviously more work for the organiser, adding promotion of the event and handling registration. There are several reasons why companies host a Coderetreat. I ran a public Coderetreat in Venice sponsored by Interlogica. The people of Interlogica were passionate about our craft and wanted to connect with like minded individuals. Three out of four attendees were not connected with Interlogica at all and the exchange of ideas and networking was great.

Sponsoring a Coderetreat is Awesome!
The hosting company is usually also the Coderetreat's main sponsor. Sponsoring a public Coderetreat is a marketing activity. Interlogica wanted to increase its visibility. While we cannot expect a huge impact from a single event, it definitely was a good start. I supported them because a Coderetreat is real value provided to participants and the Craftsmanship community. As the event was free for the participants, someone had to pay for the room, lunch, time spent on organisation, my (facilitator) travel expenses and so on.

Session in progress at Coderetreat Venice 2016 (C) Pamela AdediwuraThe sponsor deserves our gratitude and at least some "link love". The host and facilitator may create more buzz on Twitter and other channels, depending on the free time the host has during the sessions. I post at least some images of the sessions and retrospectives, drawing some attention to the sponsor as well. As sponsored event, this is part of the deal.

Finding Local Talent
Many companies have trouble finding developers to hire. Hosting a public Coderetreat is a great way to present the company. Sometimes a representative of the sponsor will open the Coderetreat and make participants aware of open positions. I recommend distributing handouts of vacancies in the room and on the tables.

Public Coderetreats are run on Saturdays to allow people to participate. Starting Saturday morning attracts only the most passionate developers, who want to learn and engage in deliberate practice. These are exactly the kind of developers companies want to hire. A lady from Interlogica's marketing department told me that "people who understand (the idea of Coderetreat) and come are the people we want to hire."

Community and Networking
The Software Craftsmanship community is growing and a Coderetreat is also a networking event. After a few Coderetreats the participants get to know one another. For me a Coderetreat is like a class reunion, I usually know at least half of the participants and some of them are dear friends whom I would like to meet more often. For beginners or people new in the city it is a great way to get in touch with local craftsmen.

A Coderetreat ends with drinking beer in a local pub in the evening. This is another opportunity to talk to fellow software professionals. At the Coderetreat in Venice, the sponsor set up a small reception including cheese, wine and finger food for all participants. (Did I mention that they rock ;-) Interlogica's CEO was amazed by the number of different people he met and talked to during that time.

Free for Participants
According to Corey Haines, one early proponent of the Coderetreat format, the event must be free of charge for participants. Many organisers ask people only for a safety deposit of ten to 15 Euro. The deposit is refunded as soon as the person shows up and is used to pay beer in the evening if the person does not. I strongly recommend using such a safety deposit to make sure that people show up. Most organisers use Eventbrite for handling the registration, because it does not take any fee when a ticket is refunded. An Eventbrite registration page might look like the one I used for GDCR14.

Promoting the Event
After setting up Eventbrite, every public Coderetreat should be registered at coderetreat.org and promoted through Twitter, Facebook and other channels. Coderetreats in large cities, e.g. Berlin or London are sold out in under a week. In smaller communities we need to allow enough time for people to get spread the word that a Coderetreat is coming up. I recommend having the registration ready at least one month in advance to have enough time for sharing and advertising the event.

Whenever I run a Coderetreat, I talk directly to local programming language user group leaders and ask for their support to promote it. Even if I do not know these group leaders, their members might be interested in coding activities. As a Coderetreat is open to any programming language, it is much more fun to have participants from various programming backgrounds. Collaborating with user groups ensures that there are participants offering more interesting languages like Go, Elexir, Haskell, Dart and so on.

you are awesomeThe same is true for women in technology. For a Coderetreat in Berlin last year, one facilitators got in touch with several local women-only programming groups, like Rails Girls or PyLadies, told them about the event and opened private registration for them. He waited for a week before making the registration public. After public registration started, the event was sold out in a week.

Being Awesome!
So if your company wants to be seen to care for craftsmanship, dedication and quality, you are looking for great developers to hire or you just want to work in an awesome company, hosting a Coderetreat is the right things to do. Even when you are not able to host a full Coderetreat, buying food for participants or covering expenses is appreciated.

10 July 2016

About Inhouse Coderetreat

What is a Coderetreat?
A Coderetreat is a full day hands-on coding workshop focused on the fundamentals of software development, software design and communication. During the day participants get several chances to try something completely different and have the opportunity to learn new ways of coding and testing, programming languages or IDE usage. A Coderetreat is a funny and exciting day for the people, sharing their thoughts on Test Driven Development (TDD), Simple Design and more.

The Role of the Facilitator
A Coderetreat is run by one or more moderators, called facilitators, who are an essential part of every Coderetreat. The facilitator guides the participants through the day and helps people to learn as much as possible. Different facilitators have different styles. (I like to explore these styles and travel to co-facilitate Coderetreats with other people, as I did for last year's GDCR.)

inHouse (cc)Hosting an Inhouse Coderetreat
In a business context Coderetreats are run inhouse and during working hours. Someone inside the company has to take over the role of the host, and care for the organisation, e.g. invite participants, find a proper room, etc. Usually this is done by a team lead or line manager, who is attending the event but not participating in coding. Lunch should be provided on-site for all participants. The lunch break is the perfect time for discussions and reflections on learning and participants should not wander off to get food on their own. Sometimes I allow lunch breaks up to 90 minutes to encourage more discussions.

Finding a Room
Finding a suitable room for a whole day can be challenging as large meeting rooms are scarce and contested resources in companies. The room must be suitable for people working on laptops in pairs and should be comfortable enough to allow for prolonged periods of working. Not all rooms are useful. University labs are not ideal because the room setup does not encourage pair working. Lecture rooms with benches are no good as they do not allow for comfortable coding. The facilitator should be able to walk behind the participants and movement between sessions should be free. Dividing participants into several rooms is possible if the rooms are located next to each other. The best setup is a single, large room with several tables, where each table allows one or more pairs working together. The best rooms are apart from the daily business, without disturbances, increasing the retreat character.

Further space is needed for the discussions and session retrospectives. Sometimes this is just an empty space in front of the room where people gather in a circle and talk, or it might be a different room - or even a light-flooded hallway. Sometimes a short walk to another room helps participants to detach from the previous exercise.

A Day of Learning and Practise
The goal of a Coderetreat is deliberate practise and learning. There is always something new to discover during such a day. Depending on the expectations and skills of the participants, the facilitator will choose suitable exercises that challenge them and push them outside their comfort zone. All exercises are based on TDD, Simple Design and Pair Programming. Even if participants are new to one or all these core practises, they will get a first experience using them. They will explore their first tests or might collaborate with more experienced developers and see how to drive their development with tests. It is a great way to start TDD. I have seen participants leave the event completely exhausted by all the new things they have learned.

Retrospective during Coderetreat at Wooga/Berlin 2015 (C) Stefan HothFor inhouse Coderetreats participation should be voluntarily. It is impossible to force people into learning. If someone does not want to attend, she can leave any time. During inhouse events I do explain more and push the participants less outside their comfort zone because they are still at work. Although it is difficult for me, I refrain from difficult or extreme constraints because I do not want to frustrate the participants. Some facilitators start an inhouse Coderetreat with a short presentation or discussion about the principles of TDD, Pair Programming and Object Orientation.

Kicking Off an Improvement Initiative
While an inhouse Coderetreat includes more teaching aspects than a public one, it is no training, there is no teacher and the participants strongly influence the day's agenda. Still it is a great way to get started with the spirit Software Craftsmanship, Continuous Improvement, Deliberate Practise, XP practises like Test Driven Development or Pair Programming and Agile Software Delivery in general. A major goal of an initial Coderetreat is to make people aware that there is more than training on the job and to spark the interest in topics like TDD or Clean Code. A Coderetreat is a great way to break the ice, because it is without any obligation for participants. I also make the whole day as much fun as possible, because fun is important for learning and I want my participants to look forward to future events. I strongly recommend running a Coderetreat to kick off any technical improvement initiative or coaching engagement.

The Facilitator's Perspective
A Coderetreat is also an opportunity for the facilitator and the host company to get to know each other, enabling further collaboration. Deliberate Practise events like Coderetreats or Coding Dojos cover only some aspects of technical improvement. Additional activities like lectures, focused programming workshops, team coaching, mentoring by Pair- or Mob Programming might be necessary. During a Coderetreat the facilitator sees how the participants approach problems, how they write code and how they communicate with one another. These fist impressions of the team's skills help to plan further learning activities.

Since I started working as independent trainer and coach in Vienna I have used the Coderetreat format extensively. Its open nature allows the participants to experience a way of practise and learning which are usually not known in enterprise environments. On the other hand it gives me a first idea of the overall skill level of the client's team and we get to know each other. I strongly recommend running a Coderetreat as kick off for any long term technical coaching engagement.

9 June 2016

Oracle Code QA

As Code Cop I want all my code to be clean so I keep my sanity when maintaining it. Some basic pillars that support internal code quality regardless of programming language are Coding Conventions, automated (unit) tests, Static Code Analysis and Continuous Integration. I discuss all of them in my Code Quality Assurance lecture (and its latest slides are here). A good development process covers all these and more.

Recently a colleague inherited a bunch of Oracle PL/SQL code and asked me for help. Being used to Java and many tools that help us keeping the code in shape, e.g. JUnit, Checkstyle, PMD, Jenkins, he wanted the same for his database code. While some programming language ecosystems are traditionally strong in supporting the things I mentioned earlier, some other languages seem to lack behind. Clearly there are fewer options for less used languages. But that must not stop us from applying the same rigour to our code. Let's get started!

Everyone is Marcin Grzejszczak todayDatabase Naming Conventions
First we need coding conventions because consistency is important. Unlike Java where most projects follow the Oracle conventions, there is no such thing for Oracle databases. Instead there are several, sometimes contradicting proposals and you have to put together your own set of rules. Here are some reasonable ones for schema objects:PL/SQL Coding Conventions
The Procedural Language/Structured Query Language (PL/SQL) was introduced by Oracle in 1992. It is a compiled, procedural and structured language. By these attributes it is similar to modern languages like Java or C#, and all the general advice for naming, formatting, commenting, function scope and code size apply. Even object oriented concepts like Encapsulation or Coupling are meaningful (to a certain degree). See my presentation on Clean PL/SQL for more details. Again there are no official conventions from Oracle.
  • Steven Feuerstein's Naming Conventions and Coding Standards contain a list of naming conventions for PL/SQL variables together with some guidelines and a discussion of rejected conventions. If you do not know Steven, he is probably the authority on PL/SQL programming and knows what he is talking about. He also outlines a way to check the conventions, which I really like.
  • Philip Greenspun's SQL Style contains a few rules on formatting SQL statements for better readability.
  • Trivadis' PL/SQL and SQL Coding Guidelines are a complete set of standards regarding naming, formatting, language usage and control structures. It is a very comprehensive document of almost 60 pages and looks really impressive.
How to Choose Your Own Conventions
As there is no standard, you need to roll your own. To get started I recommend reading all the resources above (and even google for some more) and get an idea what could and should be defined. Then you look at your existing database objects and source code. Usually developers follow some conventions and some percentage of the code uses similar patterns in formatting or naming. If one of the used conventions is in the limits of the different proposals above - and you like it - then start with it. (Starting from something that is already there reduces your options and the resulting conventions are less optimal, but on the other hand you have a bigger change to get the code into a consistent state, because some part of the code follows the rules. If there are no existing patterns in your code, if you are starting from scratch or if all you see is crap, you still need to define different conventions.)

Quality ControlStart with a small set of rules in the beginning. There should be some naming schemes, table aliases and formatting rules. If you define too many rules at once, there will be too many violations in the existing code and people will argue that adhering to the conventions is too much work. Later, when everybody got used to the rules, it is time to add more of them. You will find more specific rules during the lifetime of a project, e.g. by identifying bug patterns to be avoided in the future. Conventions need to grow. Unless you are beginning a new project and want to start with a full set of conventions, the Trivadis conventions mentioned above might be too comprehensive to start with. But they are an excellent example how a full blown conventions document looks like.

Reviewing your code, reading the provided resources and collecting the basic rules that apply and that you like should not take you more than a few hours. It is more important to start with the first version of coding conventions sooner than to start with a complete set later.

Unit Test
If you are used to JUnit, RSpec or Jasmine you will be disappointed. There is not much support for unit testing in PL/SQL.
  • Usually - if at all - developers create stored procedures that call other procedures and check the results programmatically. If these test procedures follow a common convention, e.g. raising an exception on test failure, it is possible to automate calling them from the command line or build server.
  • Another option is utPLSQL, a basic unit testing framework created by Steven Feuerstein. It works as expected, but lacks the comfort of modern unit testing frameworks. I used it to test my PL/SQL port of Gilded Rose. (Gilded Rose is a testing kata where you need to create a lot of tests. It is an excellent exercise to get a first impression of a unit testing framework.)
  • Oracle SQL Developer has some support for automated testing. Unlike utPLSQL it is driven through the user interface. Tests are created and executed through the UI of SQL Developer. A Test case is a set of input values - usually rows in one or more tables - and a call to a stored procedure. Then the updated values are compared against a set of expected values. To see this in action, check out Jeff Smith's introduction to Unit Testing Your PL/SQL with Oracle SQL Developer. It is easy to create first tests, but test definition lacks the power of a general purpose programming language. Further I do not like that test definitions are "hidden" in some SQL Developer specific tables, the Unit Test Repository. However if you are a heavy user of SQL Developer, it might still be reasonable to use it for testing, too.
  • DbFit is an extension to FitNesse, a standalone, acceptance testing framework. DbFit tests are written using tables, making some test scenarios more readable than xUnit-style tests.
  • Steven has more recommendations for unit testing PL/SQL, including Toad's Code Tester for Oracle. If you licenced the Toad Suite, it is worth checking out its testing functionality.
Unit testing is mandatory, but no single approach or framework looks superior. I believe the best approach is to evaluate the different options, using the tools you already have. Maybe create some tests for the Gilded Rose in each of the testing frameworks to see what works for you and what not.

Static Code Analysis
magnifyA vital part of code quality assurance is static code or program analysis. The source or object code is analysed without actually executing it to highlight possible coding errors. I love static analysis but have never used tools for PL/SQL myself. Steven agrees with me that we should use Lint Checkers for PL/SQL - and of course he is right. He lists some tools that add warnings besides the checks provided by Oracle.
  • A free tool is PMD for PL/SQL. PMD is my favourite code checker for Java and it works great. There are only a few rules for PL/SQL but more can be added easily. (See how I added custom rules to PMD in the past.) PMD is definitely a tool I would use first.
  • Trivadis PL/SQL Cop looks very promising. I am not sure about its licence, but it seems to be free. Rules must be checked automatically each day, e.g. in the nightly build, so tools must work from the command line. Again I do not know if PL/SQL Cop works like that. The next step would be to experiment with it and see if it can be run from the command line.
  • Another great tool is the Sonar Source PL/SQL Plugin. The plugin adds PL/SQL support to SonarQube. SonarQube is a free, open platform to manage code quality. It is widely used in the Java community. The plugin is commercial, but if you need to manage a lot of PL/SQL code I would recommend buying it nevertheless.
  • There are several other commercial tools available, e.g. ClearSQL by CONQUEST, which I did not check.
For static code analysis I follow the rule that more is better. I recommend to start with a basic tool, e.g. PMD, and keep adding tools and rules over time. In existing projects you need time to fix the violations, e.g. WHEN OTHERS THEN NULL, and starting with too many rules in the beginning creates a lot of work.

Putting It All Together
After you established conventions, added automated tests and configured some static analysis tools, it is time to put it all together and shorten the feedback loop. While you could run tests and checks manually from time to time, it would be more helpful to do so every night, or even better on each check-in/push. (Checking your code on each check-in requires you to put your DDLs and package sources under version control. While this adds some extra steps to your development workflow, I highly recommend doing so.) A tool like Jenkins or another Continuous Integration server could be used to create an empty database instance, execute your DDLs and compile all your packages. Starting with an empty database instance is important to avoid works on my machine problems. Then Jenkins should run all tests to verify that the code works as expected. The final step is to analyse your code for violations of coding convention and potential problems. Many people add more steps like generating documentation or packaging deployment bundles suitable to be deployed by the operations team's DBA.

Just Do It!
Terence Parr recommends to automate anything that you might screw up and he is right. Creating working software is hard enough, we should not bother with manual tasks, rather automate them. Further automated checks keep the quality of our software high, resulting in faster maintenance and less bugs. This leaves us more time for the interesting parts of software development - solving problem and creating solutions.