Gleek is an app that we built to scratch an itch we’ve had at for a long time. We are a software development company that works almost exclusively with remote clients. My job as a manager of remote teams is often to facilitate communication between remote and local team members. We use a wide variety of tools to help with this, be it Slack, Zoom.us, or Azure DevOps. We were always left somewhat unsatisfied when it was time to build software diagrams. Of course we tried using Visio, Draw.io or LucidCharts and, sure, it’s possible to create a software diagram using any of these tools. But to us, the support in those tools for developers always made us feel like an afterthought.
All the big diagramming products out there have decided that they need to capture as much of the “Visual Collaboration” market as they can. In our view, this broad approach might be good for making a profit but it’s not the way to create a tool that software developers can really properly and comfortably use.
Raise your hand if you’re a software developer who loves connecting boxes together
Another trend we have noticed in software development is that as Agile approaches have become ubiquitous, so has a tendency to sometimes be a bit too agile. No one here at Gleek wants us all to go back to waterfall development – we are certainly agile in our approach But I’m sure we have all experienced working in a team where some of the members have interpreted Agile to mean “I can just start coding the second I’m done with the sprint planning session.” Maybe this will work on a one man project but for most teams nowadays some alignment should be done before we start punching keys. Taking a breath, sitting down and diagramming during Planning or Refinement sessions is the best way to make sure your architects, leads and the rest of the team are on the same page before any code is written.
In our opinion, diagrams at this stage don’t have to follow a rigid process to be useful. In fact, diagraming processes and standards canı sometimes add additional friction which prevents the team from adopting diagramming as a standard part of the development process. It’s one of the reasons why people are so willing to draw boxes on a whiteboard, or with a pen and paper, but are less likely to create proper UML. There are no rules to drawing boxes to represent your software, and very often these casual sketches are the best way to do this visual software designing
The downsides of pen and paper/whiteboard is that almost all teams nowadays have some remote element – and taking pictures of a whiteboard or piece of paper or trying to jerry-rig a webcam to record a whiteboarding session, simply isn’t ideal.
Another problem with whiteboards/pen&paper is that once they’re done, they’re done. You can’t update it if you want, and good luck keeping track of it. Of course, you can plop them in version control, but you can’t modify them. Same with our competitor’s diagrams – have fun with version control and merging on LucidCharts.
So, with all that out of the way, we come to why Gleek was born.
Forgive me if you are an artistic, mouse and rules-loving developer who hates version control. I mean no offence but, in our opinion, you are a rare breed.
We have strived to create as frictionless a diagramming tool as possible, that can be used by developers in the most natural way as possible. Gleek provides a way for you to truly quickly and easily create diagrams, and we take care of the visualization.