The year is starting with a lot of projects and a great deal—an awful lot—to do. I have plenty of reading to catch up on and many milestones to meet, both personally and professionally. Among other things, I’m working on a redesign of this website and have two new literary projects underway (one of them technical).
Starting work on a new product is exciting. I always draw a clear distinction between “products” and “projects”, because their lifecycles are nothing alike. I personally prefer products: you have to think about them differently, take a radically different approach to maintenance, and, if you wrap one up properly, you can move on to the next without spending years on the same project—and, of course, you’ve added a new product to your company’s catalog.
Profitability is another matter. That’s a business-development topic, but I just want to point out something that keeps surprising me: too many software companies are determined to win projects, with all the sales effort that involves, instead of investing more in a portfolio of products that can be sold once, ten times, or a thousand times after they’re built. Can you see the difference? At the very least, companies can combine products and projects in a mixed model.
We’ve taken the first steps toward developing a new product called Smart TPL, and we’ve already secured commitments to sell several licenses. What interests me here, though, is more how we’re doing it than what the product actually does. Still, here’s a brief description.
Smart TPL is a mobile application for locally reading digital meters that use PRIME technology. This is necessary because not all installed meters—whether for residential or industrial use—can be remotely managed. An operator still needs to travel to the installation site to retrieve readings, events, and so on. Note: I’m referring to the devices installed outside a home or in a centralized panel in an apartment building to measure electricity consumption, among many other electrical parameters.
How are we going to build this new product?
Once again, there’s no need to reinvent the wheel when it comes to the lifecycle: we just need to follow good practices, which I’ll summarize below.
After some discussions with the first client to confirm their purchase, we exchanged a series of documents and agreed on the product’s required features. Those documents are where the requirements come from.
The software requirements need to be agreed upon with the client, and, above all, I need to make sure everyone is speaking the same language—in other words, that we all understand the domain, or the particular world of problems the application is meant to solve, in the same way.
This may sound trivial, but it’s vital if we want to avoid ending up in the classic cartoon about the wheel and “what I understood”…
Next, we set clear delivery dates. These are both a personal commitment for the development team and an expectation the client wants us to meet.
And, of course, at this stage the requirements—which are now well understood and clearly defined—are added to our ALM (application lifecycle management) tool. For me, that can only be our Microsoft Visual Studio Online subscription (formerly Team Foundation Server). In my opinion, it’s one of the best tools available for implementing software projects.
What about the technologies we’ll use?
Since both the team and I know the technologies associated with the .NET Framework well, we should clearly choose Xamarin to build the mobile application. This isn’t a matter of personal preference; it’s about productivity. C# experts will find it very easy, even natural, to build applications in that language, even for a different framework or API.
What’s more, Microsoft has acquired Xamarin, which suggests that it will remain in the market for many years. There’s also a large community around Xamarin.
What are the next steps?
Since I take an agile approach to software development, and this project is an obvious candidate for it, we’ll define a first work sprint in which we’ll set up the project and complete a simple feature from the requirements catalog (backlog items).
In this first sprint:
- We’ll create a very basic version of the application which, despite being simple, will already be usable on the chosen mobile device.
- We’ll prepare a mock for the backend the mobile app needs to connect to, based on REST services available inside a VPN.
- We’ll deepen our knowledge of Xamarin to implement the next sprints.
And, above all, we’ll have fun working on this new project.
I’ll write more about its progress as we complete each sprint.