Before I Jump Into *This* Project Tip…
I think before I launch into my next project tip, I want to tell you a little about my slant on the business of software development. You need to understand that I am and always have been a capitalist. I fundamentally believe that innovation and hard work, by any individual or team, should lead to success in the market. That success should translate to the bottom line of whatever endeavor to which you apply yourself.
I realize that while this view is not unique, it also isn’t ubiquitous. Not all software needs to be written for profit. I can’t name one successful software developer who has never leveraged an open-source tool, language, or operating system at some point in their career.
With that said, the slant of this, and many of my articles will definitely contain a certain amount of mindfulness towards profitability. In my 30 year career, I’ve never worked for a charity.1 Every company I’ve worked for expected me to build software either to sell or to maximize and automate internal processes. With one notable exception 2, they were all seeking profit. We all have to eat.
You just got the green-light to start your new project at work. Or maybe you have a great idea for a game, web site, or mobile app you can build. That’s great! You’re excited and you want to start coding on your project immediately. The rest of this article will outline some tools and techniques you can use to plan the project. You probably won’t need all of them on every project you work, but I suggest becoming familiar with them, since many elements you use in documenting the project will also be used in your program’s documentation.
Object Oriented Projects can Use UML
If you’ve never heard of, or used Unified Modeling Language (UML), it’s not very complicated by itself. I would call it a simple diagramming convention that helps you plan complicated projects. There are 14 different kinds of UML diagrams. You rarely need all of them. I usually introduce UML as being “like sheet music for software developers.” If you hand a competent musician some sheet music, it’s a good bet they can play the music on the page. Really good musicians will improvise and add their own artistic touches as they play. Likewise, if you hand a UML class diagram to a compentent object-oriented developer, they’ll be able to make the classes on the page. Really good ones will improvise and add their own artistic touches as they code.
Are you making a game?
Many successful games start with a game design document (GDD). It can easily be 50 to 100 pages long once it’s all said and done. GDD’s are a must-have if you are using someone else’s cash to fund the development of your game. It’s a way for investors to see what they’re paying for and gauge the likelihood of the project’s profitability.
Most good game design educational and training programs, like those at Richland College where I taught for 25 years, stress game design documentation beginning in the intro course, and requiring it everywhere up to and including the capstone class where you build and publish a game.
If you don’t have formal education on game development, creating a GDD is pretty easy if you use a template like this one from the University of North Carolina (Chapel Hill).
Is That a Database in Your App, or Are You Just Glad to See Me?
Let’s just go with the former. You can plan it’s structure using an entity relationship diagram (ERD). An ERD is a graphical map of a database schema showing table structures and all the foreign key relationships that make up any well designed relational database schema.
Making an ERD is not very hard. Many diagramming tools like Dia have database diagramming capability. If you are documenting an existing database, some times, like JetBrain’s Data Grip can generate the diagrams for you.
Consider The Business You’re In
My first tip in the series revolved around attaining the business knowledge needed to be successful in whatever industry you serve. Everybody has a boss. If you freelance, or maybe run an agency or contracting company, you don’t have *a* boss. You typically have between five and twenty, all with their own agendas and deadlines.
So, let’s talk about the non-coders in your life. No, not them, the other ones – the ones who pay your check? Naturally, your boss (or you) want to know when you can realistically launch your new project, and how much it will cost to build. You need a Gantt charting tool like Microsoft Project ($$$) or GanntProject (free and very good). If you’re one of those Linux people (and you know who you are!), you can find Gnome Planner in your favorite package manager.
Gantt Charts are the most common way to realistically plan a deadline. You set a start date, and define all the people and resources you need for a project. The project software then allows you to enter milestones and tasks, along with who is doing them, and how long you think each task will take.
Tasks in most projects are dependent on one another. For example, it’s difficult, but not impossible, to write database access until you at least know the structure of your database. There’s a planning tool for databases, too, but I’m getting ahead of myself.
Once you’ve entered all the tasks, along with time estimates, and assigned them to people on your project, you can see, based on your start date, when the project is likely to ship. Add 10-20% because things always go wrong and padding the time allows you to recover from the unforeseen with your client relationships intact.
Does Your Project Entail Starting a Business?
I’m currently the lead developer at a company that makes a software-as-a-service offering. I wasn’t around when the business formed, but the product I make definitely became a business entity unto itself.
If you’re striking out on your own, and intent on turning your ideas into marketable products, you should write a business plan. Aim to complete this in a week, because it is well worth the time. A business plan succinctly outlines the boundary conditions for your projects, and provides tools for cost analysis, competitive positioning, creating and executing a marketing plan, and so much more.
The easiest way to do this is to get yourself one of the many business plan kits. There are some great resources, including a business plan template for any word processor, available from the Service Corps of Retired Executives (SCORE), a volunteer organization whose members include, as you might have guessed, retired executives with decades of experience.
Don’t Forget Marketing
I’ve heard some estimates saying that 30% of the cost of developing software and bringing it to market is sales and marketing. Doing market research ensures you aren’t ripping off someone else’s idea. Or if you are, you are at least prepared to make a competitive product. Like everything else, there’s a plan, in this case a marketing plan. The marketing plan is typically part of your business plan, but it doesn’t have to be. You can find a template for a marketing plan in the SCORE template I mentioned earlier.
Marketing isn’t normally a skill in the wheelhouse of most software developers. Aside from that, spending your time thinking about, and executing a marketing plan takes time away from building your project. Thankfully this is something you can easily outsource. There are plenty of folks on LinkedIn, and even gig websites like Fiverr and Upwork who can help with building and executing marketing plans.
You’ll Need a Lawyer
A lawyer? Really? Yes. Think of all the legal aspects of successful software:
- If you’re writing software for someone else, you’ll need a contract
- You’ll need a licensing agreement (EULA)
- You might need help with intellectual property like patents, copyrights and trademarks, both in registering your project and defending your project against claims of infringement
You might think you can use a site like Legal Zoom or get one of those CDROM’s they *still* sell at Staples, and do it yourself. Unlike your business plan, copying and pasting boilerplate software contracts is, in my opinion, always a mistake. As Bones used to say on Star Trek, “Dammit Jim, I’m a doctor, not an engineer.” Similarly, you are not an attorney.
Even if you think you know the laws that govern your state, in my experience lawyers are useful allies because they think differently than you do. Your brain is wired to solve problems with the building blocks of code. An attorney’s brain is wired to poke holes in EVERYTHING. They will think of every possible thing that might go wrong on your project from its inception to when it ships. They might even spot potential problems with the product idea, such as excessive potential liability that comes with certain types of software projects.
If you’re working for an established company, they will likely give you the contract to sign. Never sign anything without an attorney on your side. The company who produced the contract used an attorney who wrote the contract to be, in every way possible, working in favor of that company. If the only one looking out for you is you, you will operate with a huge disadvantage.
Bottom line: find and network with an attorney. Most developers shy away from this thinking legal work is expensive. It probably won’t cost nearly as much as you think, because the cost of the attorney’s time up front is a fraction of the cost of getting sued. When I ran my own contracting company, I had an attorney review everything for a few hundred dollars for each project. You can build that into the cost of the project and gain extra piece of mind.
That’s an odd thing to say in an article about software project planning. One of the most important lessons you can learn as a software developer is the importance of shipping your product. If you spend six months planning it, that’s six months of time and paychecks while nothing other than documentation (which you can’t sell) is being produced.
If you start treating the design phase of your project like it was “real work” you risk suffering from analysis paralysis. This is where you obsess over planning every possible detail to the point where you can’t get anything done. You become gridlocked.
The design phase of your project should paint out the broad strokes. Once you have an idea of where you’re going and how long the project will last, start coding!
Coding Doesn’t Create Profit Either
Don’t forget that once you plan the project, you have to code the project. You can’t ship partial code. I sometimes shock my students when I tell them that the exercise and practice of writing code is largely un-profitable. Software developers are expensive. Your project will not reap any profits while you are planning the project. Writing code will never make your business any money, either. Shipping your code will (we hope).
Code and Ship The Minimum Viable Product (MVP)
You undoubtedly have a ton of ideas for the software you want to write, and your internal feature list grows every day. This can consume your product insofar as you always want to add “one more thing” before it ships.
At the onset of your project, it is wise ti decide what the minimum viable product is; that is, what features are absolutely essential in defining what your app does and how it works. Then as the feature ideas pile up, document them, but don’t let them affect the ship date of your minimum viable product.
Your first order of business as you begin building the MVP is to go fast, and fail fast. There will be inevitable failures along the way. Everybody knows and expects this. Your job is to keep moving. It’s better to be moving and be slightly off course than not moving at all because, just as in physics, bodies at rest tend to stay at rest.
I should clarify one point here. Velocity is a term used in Scrum and other agile methodologies as a formal metric. I’m not talking about a formal metric. The formal metric is sometimes counter-productive because there is no scientific evidence showing establishing and tracking a velocity metric contributes to the success of the project.3
I’m really talking about the psychology behind going fast, and failing fast. Your project has velocity (maybe a lower-case “v” is appropriate here) when you and your team feel like they’re making good progress. There’s something inherently satisfying about marking stuff “done”, and the more often you do it, the more exciting the project becomes.
From this point of view the best way to create velocity is to break your tasks down into manageable pieces. If a task will take you longer than two days to complete, break it down some more if you can.
Always Have a Stable Project Demo Ready
Personally, I like to get the visuals done first so the stakeholders can see something. Get the UI / UX layouts into code and shareable. Once it’s good enough to show, put it on a server or maybe a demo branch in your repo so it is always available.
As you work on the project, you will invariably break stuff. That’s usually when the bosses come by with an investor who wants to see the cool demo your boss was telling them about last week. If you ruined it in your current sprint, you’ve missed an opportunity to impress someone who might have an impact to the project. Merge improvements into your demo only after they are stable and worthy of showing off.
PMP’n Ain’t Easy (But it Sure is Fun!)
If you are really digging all of this planning stuff, you can look into becoming a Professional Project Manager (PMP). I know a lot of software developers who took the certification test as a stepping stone towards the goal of becoming a development manager.
- That’s not *exactly* true. I worked for the Boy Scouts of America for many years and I loved that job.
- Technically, the BSA is a non-profit and so doesn’t inherently have profitability as a goal. Instead they call it sustainability. It’s the same thing – they want to keep the lights on, pay their people, and be here next year.
- This has to be true because Wikipedia says so.