18 ingredients for an efficient office: Software department ideas for a small to mid-sized business
Software production can be pretty challenging. Some shops make a perfect application with no customers, scrappy startups can get a lot done with a few people and massive organizations can have thousands of developers on staff and move at the speed of a glacier.
These suggestions are for small/startups to middle-sized organizations. They are small tweaks that can have large payoffs. I offer my perspective as what used to be called a "full stack" developer with startups and small companies over the last 15 - 20 years.
More important than an efficient software team is a viable business idea that can make money! The most profitable businesses that I worked in had the ugliest code and wonkiest deployment practices, and some of the most "beautiful" highly tested applications never went to production.
1. Hire experienced developers first
You can get much more done with three experienced developers than 20 less experienced developers. One highly experienced developer can frequently outperform 10 juniors and make less of a mess. After you have your core group of developers, you can begin to hire junior developers.
2. Focus on automation from the beginning.
This includes using AI and no code tools. Use automated deployments and testing. This can be intimidating for a small team and seem like overkill. However, if you get bigger and busier, implementing automation will become a large task that is harder to justify financially. There is also a larger risk that it will go south as your workflows get entrenched.
3. Draft and strictly enforce code standards, including formatting, comments, etc.
The best code format is the one that people hate equally.
Come to decisions on number of lines for files and methods, how much to comment, etc. These small rules will force your code base to be standardized and easier for newer people to understand.
4. Limit meetings and each meeting should have a defined purpose and outcome.
It is nice to have a daily "standup" if people are in the same part of the world and your team is small. This can be done virtually as well by posting on a Kanban board or similar.
Every meeting should have a defined outcome: "Meeting to CREATE THE DEPLOYMENT PLAN for project XYZ" so the outcome of the meeting will have to be the plan itself instead of "meeting to discuss the deployment plan for project XYZ." Lots of discussions can happen without anything getting done. Having a meeting to "discuss" something gives everyone license to pontificate without being focused on the goal and the outputs of these meetings are frequently to set up more meetings.
5. Focus on the business needs, prioritize profitable activity and justify every activity
Determine the most valuable use of everyone's time. Profitability can be increasing sales or decreasing costs. Should you add a new dropdown on the user interface or do something to reduce costs? Will this activity make us money or save us money? If this can't be answered, don't do it. Discuss the P&L openly and people will come up with surprising ideas to help.
6. Use as much off-the-shelf, low code, and AI as possible and have staff meetings to teach each other how to use these tools
7. Automate tests, especially regression tests
Work together to develop a test framework and a comfortable amount of coverage: 100% coverage is frequently couterproductive. Focus on regression tests that insure that your code still works the way you expect it to. Get a system that runs your tests automatically so that it gets done whenever someone commits to the code.
Also: enforce writing tests! if a developer has to write a test for a function the function will be easier to understand after it has been written because it will need to be defined enough to test it.
8. Decide whether you will use industry-standard frameworks, and make maintaining them part of your development road map
Commit to Django, Bootstrap, or Laravel or whatever language you settled on where possible. Make sure that at least one developer has deep experience in the platform and can teach others. A few years ago, many implementations of frameworks were someone's first project and did not follow best practices. In 2023 many development frameworks have existed for more than 10 years with thousands or millions of projects being completed and thousands of tutorials and answered questions online.
A major downside in that you are committing to someone else's software. This includes problems and security holes. You will have to maintain that software. If your product succeeds your framework with be woefully out of date and it may be too costly or time-consuming to fix.
Consider longevity carefully. Many places have "the system" that was written in an obscure language 10 years ago that does some critical process that nobody understands, frequently on a machine running a decades-old operating system just so that it can "do the thing." Sometimes nobody even knows how to log in to fix it!
9. Design lots of smaller systems that can work together
This will make Individual systems easier to understand, scale, upgrade and replace. It makes the system architecture more challenging. Use agreed upon data structures to go between these systems: the data structures can then be sent as JSON between services, sent to a queue, stored in a database, sent to a user interface, etc.
You can still keep your code in a single repository (Git). Google is famous for doing this.
10. Consistently discuss the pace of software development and the tools and strategies to get things done
The industry still evolves quickly. Is the architecture still correct? Has the industry changed? Is there something new that we should be using? Some techniques call this a "Retro" or "Post Mortem." Also "lunch and learn" is a good idea where someone from the group will present something: either something new or something that they are working on.
11. See how far you can get on simple infrastructure from a vendor like Digital Ocean instead of jumping to AWS or Azure too early
There are many stories of startups getting slammed with 6 and 7 figure AWS bills. If you are efficient with your design you can serve millions of web pages a day from dedicated servers that can cost less than $100 a month. Don't spend money that you don't have to.
12. Unless you have a specific reason to do otherwise, use Object Oriented, Domain Driven Design
There are holy wars about these topics. If you have a particular use case for procedural code or functional programming, you can accomplish this by using smaller systems to do these tasks.
13. Enforce a culture of code review and discussion
Over time, people will become less nervous about this process and not take it personally. Code that is not reviewed early on can work but be very hard to maintain or fix.
14. Project Managers and full time QA are luxuries
I might get skewered for this one, but staff that is not writing code or making sales slows things down.
The "work output" of a project manager is to hold meetings and the "work output" of QA is to ask questions and figure out how to break things.
It also depends on your industry: QA is more important for brain implants than for a meme-generator website. I have worked at companies that have transitioned from a startup to a "grown-up" with this support staff doubling and quadrupling the head count of developers Meetings and planning took over dozens of hours a week.
15. Commit to a simple task management system: Trello, Jira, etc. Spend time using the tools and implementing automation features
16. If you hire UI/UX designers make sure that they understand, or are willing to learn, how to create code or work within common front-end frameworks
17. Try to maintain a “yes and…” environment
Many things need to be shelved or canceled. However, “yes and…” opens up creative solutions.
this concept is from comedy improv. So if someone makes a suggestion like "we should be able to search by first name" you can answer "yes.. and we should also be able to search by last name in the same search box!" A few minutes of this and you may find a good solution that is easier to implement than earlier ones.
18. Ask many levels of why: especially to non developers.
Many times we will get an odd request. "I need a new field in the admin application to override a price." after a few levels of "why do you want to do that" you may determine that the field is the best solution, or the person may be trying to overcome a pre existing bug in another part of the system. Or for a developer: "I need to use the latest XYZ framework " after a few levels of why they might not realize that the system already has the capability or that the task can be completed much more simply.
No comments.