WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
You can't learn in school what the world is going to do next year.
According to the Merriam-Webster dictionary, arrogance is an attitude of superiority manifested in an overbearing manner or in presumptuous claims or assumptions.
To deem to tell the software community how to successfully build software could be construed as arrogant, except my manner is not overbearing. I simply offer this humble homily up to the reader, but you don't have to read it. Contrarily, my claims are presumptuous. I think that many software projects are bungled, and I assume that they do not have to be. Consequently, one can accuse me of some little arrogance.
Worse than arrogance is indifference. That is, to write or say nothing is worse than being accused of being a know-it-all. By offering up this article, the reader is encouraged to participate in the discourse of why software projects and prognosticating seem so unreliable. Hence, you also may presume that you do not have to agree with me although in writing this you can deduce that I believe these things with a degree of certitude.
When everything seems to be going against you, remember that the airplane takes off against the wind, not with it.
Software projects are made up of time, money, and materials. That is, there is always some finite amount of time available; usually, too little. There is always a limited amount of money; again, too little. And, there is always a desire for features, and these unfortunately seldom are finite or fixed. Consequently, every project is constrained by time, money, and features to a varying degree.
Let me tackle each of these in turn. As a technologist, I am seldom in control of the purse strings and the customer will try to drive features too, so let me start with what every technologist will likely be able to mange best, time.
Every project is comprised of a finite amount of time. So Canon #1 is don't waste any time on anything that is not a deliverable. Usually, this means spend all of your time on the software—the code, the queries, and the GUIs. If you need a process document to tell you how to do the job, you are on the wrong project.
Time usage is paramount. If you are having coding standards meetings, writing how-to guides, or project planning is consuming an inordinate amount of time, you are dooming your chances of success minute by minute.
However, by referring to time expenditures I am not saying don't do analysis, modeling, or planning. I am saying do these things to the extent it makes sense. Modeling everything is useless; modeling hard stuff to leverage your coding time makes sense. Multi-thousand line project plans aren't even read, let alone useful. Think of a project plan as a storyboard. In your project, plan carefully only co-ordinate chunks of resources that have limited availability or induce risky dependencies. And, finally, analysis is critical. The documents have to be detailed and thorough and you need buy-in or sign off, but unless the documents themselves are a deliverable, requirements documents can be informal, but they must be detailed.
To reiterate, Canon 1 is don't waste time and the second part of that is that the primary deliverable should get an inordinately high amount of your time.
Canon #2 is to work on high risk, high value features first. The reason for this is that most of the technical problems hide in the high risk areas. Get these done and it's like walking down the mountain after that. Doing high value items first means that as early as possible you are building those items that have value to the customer. About boxes don't qualify and neither, really, do GUIs in general. The reason you must build value first is that time and money will always run out and the more real features you have first, the more likely it is that you will go into production at all. Dogmatically seek out risk and value and do mitigate those first, even if you get a little tunnel vision.
Very often, developers will do easy stuff like GUIs first to show progress. The customers are initially happy because GUIs are cool and everyone recognizes the visible stuff. Although this will make the customer happy at first, a GUI-first approach is wrong. GUI-centric development is the weakest form of development. Everyone should know that now. Database-centric development is the second weakest form of development. Everyone should know that, too. Building the objects first is the strongest form of development, but if you build the objects first, the customer will be a little edgy. Impatience for visible artifacts has to be managed, but building the objects first is the right way to go. Here's why.
GUIs are the easiest thing to build and all those cool components invite incessant tinkering: Move that button, change that color, re-label that textbox. Anyone can do this work and usually anyone does. The problem is that the GUI does not solve the business problem. GUIs are just pretty. Databases are also the wrong place to start. Database technology is very established, and if you build databases first, every object looks like a table and every screen looks like a grid. There are more objects in software than visual components and tables (entities). Boundary, helper, controller, and entity classes are needed. The most important thing to tackle is the code that solves the problem and this is almost never what's in the database or the GUIs.
Almost everyone has heard of the 80-20 rule. The basic rule is 20% of the problem takes 80% of the time. If you spend your time on GUIs or databases first, you are doing the easy 80% of the problem, but when that's done the customer will see what looks like a working application, but be unaware that 80% of the time is needed to get over the finish line. The second problem here is that sometimes committing to a GUI or database too soon starts to paint in the corners and may commit you to something that makes the hard stuff even harder. Canon #2 is an admonition to work on the intractable problems first.
|If you hear "we are 80% done" and there are a lot of pretty GUIs, be very wary. This usually means that the project has 80% of the work remaining and it's all hard. A real 80% done means that 80% of the business capabilities are in place front to back bar none, including the GUIs, database, business rules, and supporting infrastructure.|
Your customers will always think they need features. Like children and cotton candy at the circus, distinguish needs from wants. Unfortunately, your customer knows what the real needs and wants are, but they may not always know that they know the difference. It will require expert communication skills to get them to the point where they know what is needed versus what is wanted.
Canon #2 is assertively mitigate scope creep by starting with the premise that the answer to every change request is no! You can enforce this by offloading change requests to a board chaired by your project's sponsor. The sponsor really wants the software and knows why it's valuable, so they will carefully help you avoid risk and veto low-value drivel.
You can't manage the money. As a technologist, someone else holds the purse strings. You can ask for more, but you may not get it. You can try to spend less, but most projects go over budget. The best thing you can do as a technologist is to build the high value stuff first, so if you need more money the customer is committed and you are more likely to get it.
Canon #3 is make them love the product as soon as possible so you will get more money when you need it, and you will need it.