Single developer's perspective

Dear developers! I am looking for development tools and practices crafted for a single developer. Encouraged by a member of the community, I leave my question here separately.

I am interested in current approaches in the Atlassian portfolio (especially with Jira and Bitbucket): how to work effectively with projects, issues, and repositories with the single developer’s point of view?

Maybe an example (although partial) will be helpful: Bazaar had Solo mode.

If there is nothing applicable, I am going to send a kind of RFC, so if you know about any open issues in this area, please give me a link. Now I am gathering solutions and opinions.

That’s a fascinating question @GerardJaryczewski.

In my ~7 years working on developer content at Atlassian and contributing to this community, I have not seen anything that describes using Atlassian in “single-player mode”. Indeed, with our mission as, “Unleashing the potential in every team,” I just don’t think it’s something we focus on.

Across the longer decades of my career, I’ve had opportunity to study all kinds of software approaches from relatively subjective software craftsmanship to the attempt at objectivity with CMMI. From studying the latter, I learned about Watts Humphrey’s Personal Software Process. Since, I have wondered if agile really needed more guidance at “atomic level” of individuals, as practices that every developer should have “in their DNA”.

I’m curious about the scope of your question. What is the context for this single developer?

2 Likes

I am so happy that my topic came to you, Ian! I was pretty sure, that it go to null device, I’ve tried three times, but messages on the website suggested errors.

And I am double-happy because you show your personal interest. Awesome. Thank you.

I have a long story, but to keep it short, I will directly answer your question about an example context. (I considered many contexts up to now, but let’s go with baby steps). So let’s imagine a poor IT administrator in a company with 100 employees. He - or she - is the only one, who can develop a local software, and the company is not interested (let’s assume) in hiring a software company, but it really needs some local application.

Someone can say, that this local programmer can use a simple Jira workflow for project management (“Oh, there are so many templates, it’s amazing! Choose anyone, which is applicable for your purposes”), and can use “Hello, world!” tutorial for Bitbucket (one week later she/he will be looking through the internet for “how to reset branch to main” and “which merge strategy is better” etc), and can use Bamboo for a pipeline, or even the GitHub Actions (because his/her colleague shows how to start with it quickly, and found it more useful), and can use this and that and etc.

Now make the step back and look at the big picture: is it really necessary, all of this stuff, really?

Yeah, that is the story, which I know from my own experience, and I know similar stories from my colleagues. Gathering all the productivity tools, making them working together, and then making them easy enough in regular maintenance - it takes so much time.

Is it clear enough to go further in the discussion? :slight_smile:

@GerardJaryczewski,

Yes, that is the kind of context I was looking for. I’ve been that poor IT admin and solo developer before. Although the reasons are different, I have also been a solo developer on some projects here at Atlassian, where there are 1000s of developers. I know from those experiences how I would want to start a new project. I want to focus on my outcome, not on a assembling a lot of tools and integrating them. I want the “simplest thing that could possibly work”.

The main reason I need “dev tools” is for future me. I’m pretty much going to forget the decisions I made and the technical context after 2 weeks of inactivity. That said, in my experience, most solo developer projects eventually grow up, or at least need hand off to someone else. To me, all of those future considerations are handled by simple version control. And, for the solo developer, there’s very little point in branch-based development. It’s sometimes handy for context switching, but I rarely have reason to push branches to Bitbucket in solo mode. Indeed, there are long stretches when I don’t even push master. For solo me, Bitbucket is just a back-up or way to get code onto different computers.

For CI/CD, I often use Bitbucket Pipelines, but my typical approach is to script up the main dev tasks so I can run them locally with a quick command. That avoids the complicated debugging cycles on a remote machine, while making it easy to use any CI/CD server.

For documentation, I prefer “in repo” to Confluence. Although I’ve been the Confluence champion at 2 prior companies, I have come to prefer text markdown, over WYSIWYG. In solo mode, only my opinion matters! :wink: More objectively, markdown keeps content close to the code, which is easier to remember where to look for future me. It means the same code tools are my documentation tools. That’s less to manage.

The hardest question to answer is “to Jira or not to Jira?” When planning, I would rather write specifications, often in the form of executable tests. The suitability of this technique depends on how truly “solo” this developer is. If the needs for software really come from someone else, then we start into collaborative needs. Here too, I find it easier to collaborate on a short document, than on a backlog, especially with non-technical stakeholders. Also, I have strong opinions about limiting work-in-progress, so I refuse build a plan so big that it needs complex backlog management. That also informs my approach to defect management: fix it when you find it. Again, the only confounding factor is what to do about stakeholders. For other developers, like for a solo open-source project, an issue tracker near the code is best (like Bitbucket issues). For non-technical, I would probably try to use whatever they know already. If that’s Jira, so be it. But that means Jira is more for them, than me.

I’ve never had to suffer the kind of management that insists on specific kinds of project management tracking, like a Gantt chart. And I do my best to avoid that kind of “documentation overload” by embracing the agile principle, “Working software is the primary measure of progress.” Delivering a feature or 2 (as defined in stakeholder terms) every 2 weeks has worked well for me.

Now make the step back and look at the big picture: is it really necessary, all of this stuff, really?

In short, no. Absolutely not. I think what Atlassian tools solve for best are the collaborative challenges.

As 1 becomes 2, I would rather apply pair-programming than add a bunch of tools.

But as 2 become 4, it’s time to sprinkle in more Bitbucket, like making sure CI/CD is automatic, not per-desktop. Maybe pull requests for code review across pairs.

As 4 becomes 8, Jira and Confluence make a lot more sense as the work grows. At 8 people, there are likely multiple Bitbucket repos, with planning and documentation needs that should span across them, rather than be locked into 1 of them. Four pairs can do a lot of work, really fast, so more coordination is needed to avoid diseconomies of scale, natural to software development.

All comments are my own, not an official Atlassian opinion; however, don’t think there is any Atlassian dogma that insists even 1 person should need all our products. I’m also curious what other developers here think. I know many of them have built App businesses in Marketplace as solo developers.

1 Like

Wow. I could put my signature under almost every sentence, as describing my own experience so closely, even with Confluence and Markdown… but minus job in Atlassian :wink: Thank you for your sharing.

Of course, I don’t identify your opinion with the official company’s statement, it’s obvious to me.

I am also interested in others’ opinions, interested so much, that I submit similar questions on few other forums (Stack, reddit, and your market rivals’ communities). I am looking everywhere.

Folks! What do you think about it?

What I want to notice, especially in reference to our common career plot, is horribly long curve of learning all of this stuff. Because we, experienced developers, had so much time to learn and practice every single productivity tool, we can use them as master chiefs in any kitchen. There is no magic for us, we can even build it alone.

But what about solo beginners? They have to start early, they don’t have so much time to learn tools. And sometimes - hereby I reply to your question “to Jira or not to Jira?” - they even start with simple Jira workflows. Personally, I found them pretty useful, especially in recent releases. It’s a great, iconic piece of software - congratulations.

I have some idea how to bring simple and holistic experience for the solo developer but without the requirements of separate Ph. D.s in Jira, Bitbucket, Confluence, and Bamboo (e.g.). I think this can be achieved with existing elements of your infrastructure, although I know, that it could be a type of “a simple new feature with the plain checkbox”, which looks pretty easy to implement, but requires millions of lines of codes to work. Maybe, I don’t know.

What can be interesting from the sales point of view, it’s a simple observation, maybe naive, but maybe justified, that animal called single developer is not one of the extinct species, rather it is like the population of ants, which are usually not visible, but is present everywhere and is larger than the human population.

So, approaching the end - in Poland it’s almost midnight - I am pretty sure that there is a business to do under this story.

What do you think?

1 Like

If someone will be reading this thread for any reason, e.g. for its own inspiration, I have found a next great example of an integrated solution for a single developer’s experience: Fossil.