The software development process steps at SoftwareMill - how do our engineers build your product?
The time has come - let me take you once again “behind the scenes” of SoftwareMill’s software development process! In the previous part, I’ve described what is happening from the moment you contact us, through determining your business requirements to gathering the tech dream team to work on your software project.
Remember the analogy about learning to play an instrument from the last piece? This part has got more, like going on a tour with your band to get the work done vibe! I’ll tell you what the whole (remote) communication looks like inside our teams, what steps our engineers take to make your software fault-tolerant, and last but not least - what kind of “extra” qualities you can expect from our developers. So it’s time to pack your bags, tune up the guitars, and go - the world is waiting for you to rock it!
What is the Software Development Life Cycle?
Let’s start with some theories that will help you understand why we work the way we do. Building software requires commitment. You need to make sure that you can adapt to any changes that occur, in a way as unnoticeable to your product users as possible.
This is where some kind of framework comes in handy or sticking to the music performance analogy - a rider. A framework like that can’t be too strict but it should give you the feeling that you are prepared for 95% of the challenges that might happen along your development journey. In the IT world, it’s called the Software Development Lifecycle.
SoftwareMill’s Software Development Lifecycle
By definition, Software Development Life Cycle (SDLC) is a framework that defines the steps involved in the development of software at each phase. It covers the detailed plan for building, deploying, and maintaining the software. SDLC defines the complete cycle of development i.e. all the tasks involved in planning, creating, testing, and deploying a Software Product.
In SoftwareMill, we stick to these rules, leaving some room for “intentional flexibility” (kudos to Ward for that name, loving it!). That’s why the project scoping part of your software development is so important - because it affects the way we’ll adjust our process to your needs! As a result, we maintain a steady and predictable work schedule that can be bent a little if anything unexpected happens.
Step 1 - Your idea: general tech analysis & gathering requirements
Let’s start with making sure that our engineering work meets your business and strategic goals! Many times, we perform workshops for our clients and their development team members. We discuss the general software architecture, the software solutions’ details, and, once again, dig into details of what our clients' needs are. One of the methodologies our engineers use during these workshops is Event Storming.
Choosing the right tech stack
Here we also determine the technology requirements. And, once again, the approach differs a bit depending on whether our engineers join an already operating development team or build software solutions from scratch. In the first case, we focus on using the technology stack that is already present in the project we’ve just joined. If it’s needed, we can discuss exploring some new technologies and tools as well.
SoftwareMill’s primary Tech Stack
In the case of “greenfield” projects, our engineers will make difficult tech choices for you. We can say with pride that within the last 13 years of existence, we’ve built such trust between our engineers and clients that they often give us a free hand in choosing the tech stack.
And how do our engineers choose the right technologies? They take several factors into consideration choosing the perfect tech solutions for your project, such as:
- our hands-on development experience with specific software frameworks, tools, and software architecture and design concepts,
- our experience in solving edge-cases and knowledge of given technologies and tools,
- the popularity of IT technologies, which entails more sources and developers tools,
- the size of various tech communities (the bigger = more developers, you can ask for support),
- the commercial support offered by software libraries, tool creators and maintainers (if the client requests that),
- how much given technologies cost (i.e. in terms of maintenance and DevOps point of view),
Our engineers will list the suggested solutions that they’ve chosen, along with strong argumentation on why a given solution is better than the other in your specific case. In the end, the final choice is always yours, yet it is what we do best and are hired for: offer tech expertise.
Setting up workflow & communication ground rules
It is crucial to set up some communication rules that will work well for both sides - the sooner the better. Usually, our engineers create an external Slack channel (as it is our primary communication tool in SoftwareMill) - but we can choose something else if you wish! Both you and anyone from your team who can bring value to the project are welcomed there so all of you can have an ongoing discussion about how the project is evolving.
What happens next varies depending on the type of project. If we are joining your developers already working on the project (as team extension), the first meeting is dedicated to getting to know each other. The introduction involves determining who is responsible for what, summing up what has been done to this point and what needs to be done next. Our developers will adjust to the workflow you already have in your development team, often proposing some improvements. Combined, our engineers have over 600 years of software development experience, often helping our clients make complex technical decisions by taking the position of Technical Leads in their teams.
Interested in how we organize our remote teams' work? Download the ebook here!
The second type of approach happens when our engineers start building software for the client that doesn’t have a development team on board. We call it a “greenfield” project. In this case, we agree together on communication tools (already mentioned Slack or something else), tasks management software (i.e. Jira), and the frequency of reporting the work progress.
Overall, we work using SCRUM or Kanban methodologies, adjusting them to specific client needs. Do you want to have daily standups? How often do you want to see a demo of our engineers' work? What should the code review requirements look like in your project? We’ll determine that and lots more together!
Step 2 - Backlog: transforming your ideas into specific tasks
At this point, we already know what goals need to be accomplished and we agreed upon tools & technologies we’ll use to make it happen - it’s time to fill up our engineering team’s sprint backlog. In the situation when our developers work as a team extension, usually this process is managed by a Scrum Master and/or Product Owner from our client's team. Our engineers take responsibility for tasks brought by the client, estimate how much time they will take, and do everything in their power to accomplish them during the ongoing sprint.
If you’re not satisfied with what the software development process looks like in your current engineering team, our people will help you streamline it with CI/CD principles in mind. So as you see, they’re so much more than coders passively waiting for some new tasks to arrive - they’re proactive, dedicated, and open to standing up to any challenge!
Our software developers visiting one of our clients in Florida to work & sightsee
When our engineers take entire ownership over the project and the client plays a purely Stakeholder role, they create tasks on their own, taking the role of project managers. But there is more - organizing meetings, managing the backlog, or taking Scrum Master and/or Product Owner roles - that’s also our devs responsibility. And this is the situation where they truly thrive, which works great for both parties!
I asked my fellow developers about the things that our SoftwareMill’s clients appreciate the most about them. They mentioned qualities like great commitment, the feeling of responsibility, quality, efficiency, independence, effectiveness, experience, extensive knowledge, following deadlines, and honesty. As a result, we have several projects where our engineers became valuable technical partners, going far beyond the initial scope of work. This wouldn’t be possible if it weren’t for their maturity and feeling personally responsible for your software success!
One of our Clutch.co client reviews praising our engineers’ technical skills
Step 3 - Coding & testing: writing code and making sure it’s fault-tolerant
Time to start coding. At SoftwareMill, we track our developers' work progress in days that our engineers spent developing features for the client's product. We have been using that approach for 13 years already and, based on our experience, this is the most efficient way to keep on track with the software progress. Our software engineers are constantly solving very complex and demanding issues during the development stage. And when they do, they need to be extra focused and careful - that’s why our software development company tracks our engineers progress in Man Days, not hours.
Moving on to the development itself! What kind of features will our engineers add to your software? Which aspects of the code are the most important ones? Are they doing pair programming or not? Everything here is project-dependent. So let me give you examples of some interesting challenges they’ve encountered in our clients' projects. Who knows, maybe you’re currently struggling with similar ones in yours!
Inside one of our healthcare projects, our developers designed a subsystem to manage the medical records collection process. They’ve also designed and implemented a DSL to formulate the critical business logic. Thanks to those actions, our client could focus on what they cared about the most (scientific research) as we’ve made it easier for them through our engineers' code.
In another case, our clients' entire system ran as one large Akka cluster, which was a clear misuse of this tech solution. The main reason for this was to use actor-based communication between services. Thanks to our devs' re-implementation of those two services and switching communication to Kafka, the number of lost messages between services and the service startup time have been significantly reduced, the flow monitoring has been improved (thanks to Kafka metrics), and cases in which the service did not respond because it "fell out of the cluster" have been eliminated.
We gathered our lessons learned while consulting clients and using Apache Kafka in commercial projects inside an ebook - you can download it here.
Last but not least - one of our clients struggled with a tight 3-month deadline to release their software MVP. Along the way, the requirements have been changing rapidly with new API integrations constantly arising. We’ve managed to adjust our development teamwork to meet their requirements and deliver a functional software solution.
One of our clients' video review
When it comes to the testing stage, it depends on the role our engineers play in our clients' projects. If they’re operating as team augmentation, their software is usually tested by the client’s dedicated QA engineers. When our software development service teams are working on the project end-to-end, it’s SoftwareMill’s project team responsibility to test the delivered software to the bone. Thanks to our Continuous Delivery approach, it’s never like our devs are waiting for code to be tested and doing nothing in the meantime. On the contrary - as soon as they hand in one piece of software for testing, they’re starting to work on a new feature or picking up the one that's already in progress. As a result, the whole development process goes very smoothly, without major holdups, as they're creating software with an agile model in mind.
Step 4 - Demo: showing you the results of our engineers' work
Before we go live with your software updates, our engineers will present to you a demo of their work. Step by step, you’ll analyze together what has been done during the sprint and what will land on production if you say the final “yes”. This is the time to suggest some amendments or give the green light to the progress made. After this, with a clear head, they can focus on what the whole process was about: providing business value!
One of our Backend developers told me that she once heard at a conference that “contractors come in, make a quick buck and leave”. I can assure you (based on our clients' opinions) that our engineers always look at the long-term perspective of each piece of software they build to avoid any unpleasant surprises in the future. We’re known for developing software so complex that it would be impossible for our engineers to simply “jump in”, code something, and then not give a damn about the results. On the contrary - usually, they need to dive really deeply into the project domain and tech requirements, to propose solutions that will actually fulfill our client’s needs.
As an example: we once acquired a project from a very complex and demanding domain. To understand the code, our software engineer had to study a scientific paper written by an author connected to the client. It was very advanced and required lots of attention to understand. Yet, thanks to his effort, the client received a much better documented code, with software edge-cases clearly identified. The “stereotypical” contractor wouldn’t probably take their time to do that - so I guess you see the difference now.
Step 5 - Ship it: making all of your software updates & new features live
The final step of the whole cycle - going to production with the new features or the whole software product. Thanks to all of the steps before, this is the easiest part. After the release, we can discuss about ensuring you the lifetime code quality warranty. Ask us about the details here!
And then… Repeat!
As I’ve mentioned before, during our software development process, our engineers use SCRUM and/or Kanban methodologies. This means that each portion of work is divided into sprints (1 week, 2 weeks, 2 months - you pick!) and after coming to a full circle, the steps repeat themselves. We’ve tested this approach on hundreds of systems delivered through 13 years of our existence, and it’s definitely working best. You have the frames that are understandable and easy to follow for the whole team, yet you can always introduce some improvements and amendments if needed.
But what about maintenance?!
Let me be frank with you - we’re not huge fans of limiting our engineers' role to strictly software maintenance. Why? Because it’s a bit like a waste of their talents as they are much more proficient in coming up with some new tech solutions, developing additional features, and discovering improvements that not many software engineers will even see.
Our software development services reviews on Clutch.co
Don’t get me wrong - of course, as long as we’re working on your software development processes, we ensure software maintenance as well. But you can’t request our “on-demand maintenance” offer as we don’t have one. Why? Because it’s completely unviable (money-wise) for you as a client. Instead, we offer to teach your in-house engineers everything that’s needed to support your software & prepare detailed documentation to make the software support process easier. And remember - you’re always welcome to come back to us whenever you feel it’s time to perform some major update of your software development project!
Conclusion
Hope these 5 development process steps will help you understand what exactly (and why/how) our engineers do, to ensure the extraordinary quality of your software. How long will your software development tour last? It’s entirely up to you, The Rolling Stones have been on tour for 60 years already, I dare you to beat them with such fantastic results as well!
But on a more serious note - the sooner you’ll start, the better. Simply reach out to us here and we’ll build the software development team of your dreams!
Check: