This Wikipedia page on continuous integration is actually a good resource for computer programming best practices.
The 90/90 Rule: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”
~ Tom Cargill
Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.
Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.
I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:
Guess. Apologize. Compensate. This is a nice slide from a talk by Jonas Bonér, CTO of Lightbend.
Three golden rules for giving code reviews, from this article on sofiacole.com: 1) Ask questions rather than give statements, 2) Limit personal preference, and 3) Check its purpose.
Regarding the second rule, I don’t know anything about it, as I’ve never been on a team that allowed “personal preference.” Each team (or company) agreed on coding standards, and used them.
These are a few notes on Apple’s Swift open source development project, taken from this mailing list post by Apple’s Chris Lattner:
- Open source is pretty great. It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.
- Open source also brings challenges. I think it is fair to say that “open design” is slower and less predictable than “closed design”. However, the end result is significantly better, and therefore the tradeoff is worth it.
- Software scheduling (particularly with open source) continues to be difficult-to-impossible to predict.
- It is *good* to have high goals, but we need to do a better job of communicating that “goals” are not “promises” so that people don’t feel misled.
“You can use an eraser on the drafting table or a sledgehammer on the construction site.”
~ Frank Lloyd Wright
Using FPA, I quickly worked through several of our largest projects to determine our productivity rates, and also noted who worked on the projects, what technologies were used, along with a few other details. In short, in a few days I was able to create a database of our historical software development speed.
The last few weeks I've been looking at ways of estimating software development projects using "Use Cases". I'm all over Use Cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.