The two most common business models among software companies are based on doing projects for clients or investing in product development. While both models can be rewarding and profitable, there are important differences that might make one model more appealing than the other. Moreover, initial investment and future predictability for those models are quite different. While one provides return of investment in a short period of time, the other requires a lot of time and money with unpredictable future but potentially much higher rewards.
Projects for Clients
Your clients are contracting your company for various reasons:
- They do not have expertise or tools to do the job themselves
- They do not have time to complete the task
- It is cheaper for them to contract your company than to do it themselves
To survive, you’ve got to keep wheedling your way. You can’t just sit there and fight against odds when it’s not going to work. You have to turn a corner, dig a hole, go through a tunnel – and find a way to keep moving. – Twyla Tharp
Customer is unhappy with how the provider works. Due to some contractual and logistical reasons customer cannot change the provider so he chooses to force the provider to improve by adopting more iterative and incremental way of development together with other Agile practices.
Provider is not happy with the decision. He is risk averse and any change is considered a risk. Risk mitigation of this transformation receives bigger priority than the transformation itself. Management is so concerned with risks that it does not even try to understand what the transformation is all about. Any deviation from the Waterfall model and practices established years ago is considered unacceptable.
I am often asked by non-programmers to explain what I do and how I do it. Following is my answer.
I am a programmer and, like many others in my profession, I am a nerd.
“Wonderful thing with nerds: they’re enthusiasts. Not having a life means you get to love things with a passion and nobody bothers you about it.” – John Burnside
Many think that computers are really smart. They are not. They are as dumb as it can be. What they excel at is crunching numbers very quickly. They do not know how to think or reason. They do exactly what we tell them.
The job of a programmer is to translate real-world problems into numbers that computers can understand. A computer is like a child that will do everything you tell him to do. What you want him to do is irrelevant; the only thing that matters is what you tell him.
On rare occasions when my daughter does actually listen to me, our relation is similar to the one of a computer and a programmer. I’m trying to make her do something and she’s testing my patience by doing what I tell her to do instead of doing what I want her to do.
You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.
There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).
- Some kind of a project management tool or a task tracker
- Version Control System (VCS)
- Continuous Integration (CI) framework with jobs for each phase from the build to deployment
I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development.
Iterative and Incremental Development
Iterative and Incremental Development
Iterative development was created as a response to inefficiencies and problems found in the waterfall model. Modified Waterfall, Rational Unified Process (RUP) and most, if not all, agile models are based on iterations.
General idea is to develop a system through iterations (repeated cycles) and incrementally (in small portions of time). Through them team members or stakeholders can learn from their mistakes and apply that knowledge on the next iteration.
The waterfall model originated in manufacturing and construction where changes are costly and investment in design of the production line is often much less than potential loss if the actual production fails. It is based on idea that planning and design costs are much lower than those used in the actual production.
## Software development life-cycle (SDLC)
The software waterfall model often uses some variation of following phases:
- Requirements specification (Requirements Analysis) resulting in Requirements Document
- Software design resulting in Software Design (SD) document
- Implementation resulting in the actual software
- Testing (or Validation)
- Deployment (or Installation)
I tend to discuss things openly and often with my colleagues. Before I start Google-ing for some solution, before I start banging my head around some problem or before I start designing an application or some new feature, I tend to consult my coworkers and see whether their experiences might help. At other times, I see someone’s commit and became curious about the reasons for the way that someone implemented the solution or I might see the better way to do something. The list goes on and on… In all those cases, I prefer to get up, pair with someone and work it out. Ideally, that someone is sitting next to me. Those I communicate with do not seem to mind. Quite contrary. Unless they are very good at pretending, they act in a similar fashion and seem to do the same with me. All in all, there is a lot of communication going on, great ideas floating around and, ultimately, some kind of shared knowledge and ownership is established. I truly believe that those discussions are what makes us all better professionals.
Not every day is sunny in Barcelona.