Communication boost in software development
There is no salvation in complexity; the only sin in progress is the wasted of time.
The actual code name devpulse and the core concept of the product is familiar to a limited few, since it was in operational use for some time among our team and some of our colleagues in the industry, but the thought of turning it in to a public tool for software development teams was put off only until recent.
And now that the work temp is starting to pick up madly as the release date is mercilessly closes in with rows of deadlines to be met, I feel that it’s time to lift the curtain a little bit and talk about the upcoming releases back ground, you can also keep track of features and mechanics we are bringing in to the system in our weekly updated series “Attention to Detail” when we present a digest of key features that will determent the functionality and usability experiences of the service.
Some background
The first operational bundle of devpulse code which could be called the great grandmother of devpulse was cooked up somewhere last year exclusively for the Programeter team internal use and reasons currently unimportant.
What is important is that it slowly started to catch on, with zero efforts put in to its promotion at the time, devpulse helped connect developers in the team via relevant and pragmatic information that actually help drive the development process better than any annual meeting or status report which are usually so filled up with clutter and formal jibberish or just too long and to boring to sustain attention long enough to be effective without killing the work drive.
Devpulse approach to communication
The relevant bits of information I’m referring to are development activity record and actual changes in data you’d usually had to track down and gather from a lot of different tools like code repositories, task trackers, bugs trackers, and more of the lot. With that in mind it’s only fair to state that at times putting together a general picture of the “team effort” and overall activities happening within a project is a task in its own right.
And that’s why we needed devpulse, which is pretty much an automated delivery boy, tracking changes, labeling them and displaying on a single easy to use activity stream.
Big step with going public
Luckily we’re hardly short sighted enough to think that the product was show worthy at the state our team and office building buddies used it, in the beginning. So before showing it to the public we sat down and dissected our birth child in to individual features that in sum make the product and started re building and modifying them to create a better experience and broaden its functionality for team communication purposes.
The log of these changes will be available on our blog on weekly basis as they are implanted in to the system, discussions are always welcomed at our “Attention to detail” series, this week we’ll be talking about the evolution of the user profile system and reasons for the changes made to it.
Why Skype instant messaging is more important than it’s VoIP functionality?
Yesterday, I was one of the millions waiting for Skype client to let me login into the service. I received unusual number of phone calls yesterday evening: my father was calling me and complaining that his “internet” is down as he can’t login to Skype, my colleagues were trying to reach me through chat inside our google mail and my friends were calling to my cell instead of sending instant messages.
Having few moments to think, I have realized how Skype has become a indispensable tool both in my business and personal life.
Interesting, that what I missed the most was instant messaging functionality and not the voice calls of Skype. For voice calls I could easily pick up my phone, but there is no reasonable alternative to group chats I use extensively. That has lead me to the conclusion that actually great success of Skype lies in it’s great instant messaging functionality and not just the VoIP. Killer feature of Skype is simple ability to create group chats and give those chats the names. Interesting if Skype people also realize that and if they are going to focus more on improvement of IM functionality in it’s next versions.
Project wallboard and stream of events
I believe that using wallboards you can improve culture and climate in your team a great way.
First of all, wallboard is an awesome tool to introduce transparency into the team - anyone who enteres the room knows instantly whats is going in the project and that helps to create trust between team members (both external and internal).
Secondly, it unites the team - it clearly communicates the message, that we all work together on the same thing and we are going to make it happen!
Finally, this is a good way for any team member to know all the time what’s the status of the project and at the same time not being interrupted by all sorts of email/im/growl notifications if something happens - you just glaze at the wallboard whenever you’re ready to be interrupted (i.e. you are ready to consume the information).
Atlassian, the great company behind products like Jira, Confluence, Clover and many others, is holding a wallboard competition. Seeing that almost all wallboards (enrolled in competition) are based on intelligent consumption of events that happen in tools used by the team (helpdesk tickets, monitoring systems, bug and task trackers, version control systems, billing systems, continuous integration and others) made me even more believe that devPulse as a semantic aggregator of events is heading the right path.
P.s. our sister product - Programeter has also submitted its wallboard to the competition and it uses RSS feed produced by the devPulse to display the project event stream. Please take 1 minute (the video is 1 minute long) of your time to check Programeter’s wallboard and give it your vote if you like it!
devPulse public beta is here
After several months of hard work devPulse is ready to be launched for a broader audience. Today we are opening http://devpulse.com/ a publicly available beta version. We have completed around 10 iterations/sprints, shown prototype to more than 100 developers and gathered valuable feedback from our initial users which has been as much as possible integrated into current version. Here is how it looks like today
For those who didn’t follow us from the beginning, devPulse is an online service that helps developers and their colleagues to easily share software project activity streams inside and outside the team. It’s a realtime feed that includes events from code repositories, task managers, issue trackers and other relevant events in the daily software development ecosystem. For example, open source developers are using devPulse to share activity stream of project with their community. Commercial projects use pulses to improve communication inside distributed teams and help each team member to be aware of changes happening in the project.
One of the important improvements over initial vision of the service, is that each event delivered by devPulse has meta-information attached. Unlike message in twitter or facebook, each message of devPulse has a type and set of fields describing the event. For example, we have types of events like: registration of a new ticket, commit of code modification, resolution of the defect and so on. Such meta-information allows smart filtering of notifications and also numerous scripts and tools to be written on top of the devPulse API. We call it a semantic events stream.
devPulse is still young and we are looking for more feedback from you. We have established feature feedback site and community support forum. If there is something wrong or missing, let us know.
Useful links and guides if you plan on using gerrit
I have wrote previously how github is missing a very important feature - code review. This led me to a decision to use gerrit in our development team. I am very intrigued by the fact that it has a Java
based version of Git (JGit) integrated in it. So, basically, when you want to submit a code for review, you just push it to gerrit, like to any other git repository. Then reviewer pulls changes reviews them and inserts her comments through gerrit web ui. If review is positive, the you merge your changes into origin/upstream repository. All this seems exactly what we need, so I decided to give it a shot.
The latest stable version available at the moment is 2.4. You can grab it here.
Official documentation is quite ok for an open source tool - that means that you will have to bend your brains a little bit. Here is a couple of more links about using and installing gerrit: awesome guide by unethicalblogger and installation guide by Greg Meiste.
I started my installation with a desire to run gerrit from a JEE container, as we already have an Apache Tomcat running on our server and embedded H2 database. But had no luck - during deployment gerrit crashed with an exception that I couldn’t even see. Official documentation says nothing about configuring logging and surfing through source code didn’t help me much. So, I had to go with a standalone installation.
I am not good at configuring httpd - configuring access to gerrit through reverse proxy together with ssl and authentication was a bit tricky, since I didn’t want to break access to other apps working through mod_jk. In the end simple copy paste from the guide and correct ordering of various parts in site configration did the job.
The next step was to configure gerrit itself: projects, permissions, public keys and ssh access to the gerrit shell. Configuring public key is very simple and other steps are described by unethicalblogger very well. Though, I must say, that ended up with a little different set of permissions than unethicalblogger:
I had to add “Forge Identity” permission on the range +2 since emails that we use to loggin to gerrit do not 100% coincide with emails/names that we have in our public/private keys. Also I have forbidden access to both anonymous and registered users - only developers (the group I have created myself) and administrators can use gerrit.
I haven’t yet tried using gerrit in our projects, but now I am ready to do that :)
If you are going to use gerrit and you are having troubles with installation - ping me as I may have some ready solutions for you! :)
How Skype can become awesome for developers
Skype is a best tool out there for having team-wide conversations voice, video and text. But, it has some deficiencies that make it almost unusable for developers throughout the day. Let me elaborate on that.
While I am writing software I usually don’t like to be disturbed - it is not easy for me get into the flow and loosing it doesn’t make me feel better. For each part of the day I’d love to have at least couple of hours of uninterrupted work - I want to be able to manage my level of focus and time by myself.
Now, that’s a lot to wish for :). I am responsible for architecture and design of our products, so, it is natural that my teammates want to discuss or consult with me about their solutions. And I am ok with that - that’s a huge inefficiency if a colleague is not able to move on with her task and is waiting for me. But, on the other hand there are people whose messages I’d like to postpone until I am having a pause.
So, how Skype can be better for developers? It is simply, I need to able to configure statuses by myself. In other words, I need to have a status somewhere in between of “do not disturb” and “online”. A status where I can tell “do not disturb” for 98% of my contact list and have all the messages delivered for remaining 2%.
Do you have similar experience with Skype? Or maybe you know some tips, how can I configure it to be less intrusive?
P.S. I can’t understand developers who have all sorts of Twitter, Skype, email and other notifications popping out all the time. I think such notifications should be kept to a reasonable minimum - I agree that there is information that needs to be delivered right away, but definitely notifications about somebody coming online or going offline are not part of that :)
Starting a new project
Every developer loves to start a new project. (Sometimes) You can choose all the latest exciting technologies; usually there is no legacy code involved, so everything is clean, elegant and neat - is there anything more elegant and neater than a empty sheet of paper? ;) I doubt it! Start of the project is the time when everybody is super excited, there are no deadlines yet, everybody is pumped with enthusiasm! But as the time goes on people feel less and less attracted to project - vows are forgotten (“we will have 90% coverage by unit tests”, “no copy-pasting”, “no hacks”), stupid requirements get into the way, project manager is pushing deadlines… and all the love has gone…
But this period of enthusiasm doesn’t happen for nothing - it actually plays very important role in the project! First of all, this is the time during which developers are the most productive and enthusiastic, so good manager knows, that this is the time for most complex and risky requirements.
Secondly, experienced developers recognize that exactly at this time they create the basis for the whole project. It is like a DNA of the person - all goods and bads will be copied all over the code based, either directly (copy-paste) or indirectly - show a bad example for a junior developer and you can be sure, that she will do exactly the same somewhere else. Tell me how many times have you settled for a ‘not so good’ solution only because you have seen ‘not so good’ pieces of code already there in the project? And how many times have you checked in such solution, when the code otherwise was clean and neat? I think to my self that the moment you lower the bar to anything other than excellent, you open the gate to the enemy :) It is just a matter of time when he gets in!
So, next time you start something from a clean sheet - remember about DNA and don’t rush too much - try to start with good and elegant examples for your teammates and they will be ashamed to contribute anything worse. This is how you set up the culture in your team! This is how you choose the route to great products loved by your customers!
Github is missing one important feature - code review
I need to setup code review procedures for products that we develop. We tried Review Board while we were using SVN. Although it is a nice tool, the fact that your code remains unversioned for the whole procedure seems kind of a strange to me. So, I hoped that distributed revision control system would suit best for this.
First I saw Kiln and in my opinion it sets up standards in modern code review processes: you can accept and decline changes + assign code reviews to teammates. One thing is very appealing to me: you create a blessed repository and then fork it for integration purposes. Developers commit code to integration fork, then code review takes place and if everything is cool - code is pushed into the blessed repository. During all this process code stays under version control - very neat. But I don’t like 2 things about Kiln: a) 25$ per user per month seems too expensive for “on demand” version b) and if you decide to host it yourself the it requires a Windows server.
Since Kiln is too expensive for us and github is sort of a de-facto standard for git hosting, we decided to go with it. Thanks to git itself and awesome documentation on github, using it as a revision control system is a breeze! Unfortunately, code review workflow supported by github is not that cool - it stands nowhere near to what Kiln offers. And that’s very sad.
First of all, everybody has to have a fork of the blessed repository. This sounds like a lot of routine overhead: to push something one needs to push it to her fork and then request pull from the fork. So, whenever my teammate needs to push something quick required for all of us to sprint on - it takes too much effort. I thought to overcome this by creating a blessed repo and then forking it inside the same account to create an integration repo. But github doesn’t support this - one can fork only into her own account (i.e. I cannot fork devpulse/devpulse-blessed into devpulse/devpulse-integration).
Secondly, there is no central place to handle pull request - I would like to be able to establish process where everybody is reviewing everybody’s code and I cannot create and assign code review tasks within github.
Now, to be honest, there are some feature that support reviewing code in github: you can see diff of the commit and add comments to it, but I cannot figure out how to use those without to much routine. So, at the moment, seems like github works quite well for open source projects with a “gatekeeper” organizational pattern (i.e. one particular person is responsible for letting code in or not and everybody send her pull requests). But, it doesn’t support setting up code review for privater repositories where peer review is required.
My next option is to setup gerrit somewhere on our servers or go back to using Review Board again, which doesn’t make me happy at all…
How have you established code review process? Can it be used on github?
Applications without API are doomed
Nowadays not only people talk to each other - having an application that is not able to communicate with other applications grew out to be a huge “minus” during last couple of years.
Even though many applications are developed for certain niche - either based on customer requirements (e.g. Atlassian toolkit vs IBM’s) or target applicability (bug trackers vs time management vs code management), they still are generalizations. This means that customers either bend their processes to suit the tool or move on to use another ones. So, from the customer’s perspective good API is a possibility to fine tune the application to fit her requirements.
Another way of using API is pulling the data out of the tool and feeding it into another one to perform data mining tasks on it. For instance, Jira is an awesome tool for tracking defects, tasks and planning iterations, but it is not the best tool analyze trends and metrics, that could be derived from tracking data. Or consider devPulse which puts streams of events from different data sources into one single feed - even if each specific tool that you use has such a feed, aggregating them all together without API-s is very difficult.
If we look at this topic from the software vendor’s point of view, then enabling customer to extend functionality of the tool is a way to ensure that customer would continue to be happy with it even if her requirements or position in the niche changes. Also having an API makes you more open and trustworthy. This may sound stupid at first: you give your customer a possibility to switch to your competitor and take all the data with her, but it actually works vice versa - the openness wins you whists in eyes of your customer. E.g. my thoughts usually go along lines: “why not to try this tool - if I don’t like it I just move to another without loosing my data”. It sort of a lowers entrance barrier for you.
What are your thoughts on this topic? What mechanisms you use to let your customers extend your apps?
Are user lists and source code underrated?
What are usual places that you (as a developer) search for solution to a problem or task with a particular technology or library?
I remember, that when I started to develop software, my first to sources of solutions were manuals/guides and google :). Guides were “no brainer” right from the beginning and google became very obvious with popularity of blogs - chances are that some other developer has faced the same problem and posted solution on her blog or somewhere in a public wiki.
Later, I found out that, it is even more rewarding to search through mailing lists of framework/library users, as these lists are devoted exactly for the purpose of asking and sharing solutions to problems. And some of them are not even posted anywhere else besides the user list. My favorite tool for digging in mailing lists is nabble.com - sometimes it is slow, but other than that it is an awesome tool (at least for lists of open source libraries).
Finally, I think that every developer should have source codes of all libraries/frameworks that she uses attached to a project in IDE. Source code is a fantastic source of all kind of knowledge about framework - you can always put a break point and check out for yourself how the particular functionality works. Also seeing a source code helps me to decide if particular library is really worth using - it is quite easy to see if code is too rigid or is not clean. Having such opportunity is a huge advantage of open source! I remember times, when I had to decompile JDBC drivers of a famous DBMS vendor in order to understand why my application didn’t work with particular configuration and even taking into account that the code was decompiled, one could easily see that source code is a mess.
Probably, for all more or less experienced developers all this is no secret, but I hope that at least for some of you this could be a good reminder, so you would try one place more before breaking the flow of your colleague ;).
