In this post I want to lay out my software development process for small and medium-sized projects.
I'm convinced that building software is deeply linked to interpersonal interaction and communication, because the goal of building software is always to solve a problem for the client. Without a deep understanding of the problem, you can't build a fitting solution. This is my personal approach for a specific type of projects and is not meant to be seen as a one size fits all because that doesn't exist.
This approach is e.g. not suitable for a small business that simply wants a Wordpress site with a standard theme and a domain.
At the first meeting, the problem is laid out by the client. Most of the time the clients don't know what the best solution for them is or how it could look like, but they definitely know what pain points they have with their current solution. So the first step is to listen.
It can be a very emotional conversation if the problem is a major one for the client, so the software engineer in mind should stop thinking about technical solutions and focus on those emotions. Understanding what causes this mood in the current solution is the best way to identify improvements.
Good consulting is providing a service and not only a technical solution - the problem being solved should be seen in this context.
The next thing should be to echo the pain points and describe the current process and how things work today to make sure that you share the same mindscape. If the client responds in a negative way, ask for clarification. You have to be sure to understand the problem on a superficial level after the first talk so you're able to vaguely define the scope and complexity of the project.
Now back in the office I sketch out the problem, define abstract concepts and creatively think about the problem, in short: brainstorm. It's not possible or reasonable to think about data structures and business logic at this point. It only matters that you've got a good picture of the problem and try to think out of the box to solve the pain points that you've extracted in the first talk.
Prefer the plainest solution and think about ways to reduce already solved problems to this specific problem (experience and theoretical knowledge can boost this step), but don't get trapped in details.
Show your ideas that you've brainstormed. They don't have to be elaborate or complex (although they should not be completely out of touch with the problem being solved), but it will show the client that you've thought about the problem and are motivated to solve it in creative ways. This talk is also very good to motivate the client to think about possible solutions, although they should not think about implementation details - e.g. they've heard about Angular.js and insist on it despite the fact that they haven't communicated it as a requirement and don't really know what it is - the focus should be shifted towards problem solving, not towards engineering.
If the problem is well-defined, prepare a list of possible solutions and what advantages and disadvantages they have. List all possible solutions with a small description and pro and cons and finish with a conclusion that favors a specific solution in a reasonable way.
Most of the time a CEO doesn't care about the details, they have a problem with some requirements, a deadline and a budget (also known as the project management triangle). Giving them a simple and effective way to make a decision is part of the consulting service.
After I've found a common ground with the client, the first UML diagrams can be drawn and the use cases can be defined. In this step it is essential to understand the problem profoundly, because the technical analysis should find edge cases that the client is not aware of e.g. do their employees have IDs that identify them without ambiguity or can two guys named "Jon Snow" with the same birthday cause a problem?
Write down any problems that could occure and assess their relevance and contact with reality. Some problems are just theoretically relevant, although it's a balancing act to differentiate, e.g. using SHA1 for file hashes could be / is a security threat in the very near future. Try to list all possible solutions for these problems and their advantages and disadvantages - this is relevant for the third talk. Colloquial language is preferred so there is no terminology barrier. I've seen it too many times that computer scientists use words in a normal conversation that their dialog partner don't and simply can't know. This doesn't help the customer and should be discouraged.
If there is data provided by the client, make sure that everything is clearly structured and there are not inconsistencies. If an error happens here, this can multiply the time efforts of the project.
In this talk you're the one who's mainly talking and asking questions. Describe all problems using colloquial language and sketch solutions. The important part is that the client has to choose which solutions for those technical obstacles should be preferred and he should be well-informed about the trade-offs. This is important if you ever encounter a problem due to technical limitations of the chosen solution in the future, so make sure that you've explained all the disadvantages in great detail - communication is important to seed understanding of every step for both sides.
Expectations that are unspoken by the client can be real conflict points in the future, so use this last talk before any code gets written to make sure that there are no hidden hopes and obviousnesses, e.g. I've seen many projects where a secure role system was expected but not properly communicated and was therefore poorly implemented. It's not always one's own fault, but you will be blamed because people are not as rational and objective as desired, so it's in your interest to minimize and eliminate those hidden conflict detonators.
Now it's time to build a small prototype which shouldn't get confused with a MVP (minimum viable product). You can build some interactions that outline how the users or the client can interact and solve their business problem.
In order to minimize confusion, try to use the design specification if the corporate design of the client defined UI elements without investing too much time styling the prototype. This prototype is important to further verify that you've understood the problem and have a working solution in a PoC-manner.
Demonstrate the prototype. Most of the prototype should be nothing more than a click dummy, so be sure to fill the demonstration with vivid verbal explanations what would happen in the final product.
Don't get caught up in the details and make sure that the client is not pedantically searching for inconsistencies in the prototype and explain the purpose of the demonstration.
At this point the client decides if he likes the solution that was chosen in the first conversations, so it's important to listen to criticism carefully. The good thing about building a prototype is that your pride can't be offended, because you've not given 100% yet - getting emotional due to criticism is unprofessional, but unfortunately not too uncommon, so it can be good to have this bumper first.
On a professional side this prototype can be compared to a mockup used in architecture or other fields of engineering and is possibly the best way to show the final product without wasting resources.
Now it's time to
git init and start the project. I don't want to tell you too much here, because this is big enough for a bunch of other blog posts and people far smarter than me already talked extensively about this topic. — tl;dr there are software engineering techniques that can and should be applied for professional software development.
The important part is that you get feedback for every iteration, regardless of the used method e.g. agile, waterfall, etc. and use this feedback. Unit tests and building reusable components and following best practices and taking security into account is taken for granted and should be accounted for in the budget because they take time without getting visible features for the client.
Testing the final product
Give the client the product with a guide which explains any interaction and elements (e.g. using screenshots) and demonstrate the software and the features. This can be seen as the final handover. If all expectations are met, both parties will be happy.
Due to time constraints and budget limits there'll be definitely bugs in it, so calculate some time for the warranty and explain to the client that the bug fixing time is normal and reassure that you'll handle all incoming bugs at the first weeks or months.
After this time you can negotiate to support them with a price tag.
I hope that this description of my process makes it clear that communication with the client is the most important part for a project besides the fact that the software has to be developed professionally.