I have questions about your project; you should have done the thinking already.
I have chief in my job title. Does this makes my opinion count for more? Not really, I just have more paperwork to do; more board reports to write; fewer things on my to-do list that I find interesting. Because of my so-called job title, I’m asked to review / rubber stamp projects and approaches because no-one likes to take reponsibility for the decision. This means more meetings and less time actually building things. What’s frustrating about a lot of the meetings is that people aren’t prepared sufficiently. They aren’t prepared to do the hard work up front; they simply want to be able to carry on as they’ve always done. I’m not Bill Gates, and this isn’t one of his infamous technical reviews, but if I can get to the stage where you sound ill-prepared; it’s not going to end well.
Code analysis is good; some code analyzers are closer to my definition of useful
I quite like LGTM since it doesn’t tend to flag up that many false positives when scanning your code. The problem with a lot of the code analysis tools like spotbugs, sonarqube, codacy etc1 is that they often apply rules without understanding the context or the style of the code in question; having false positives as shown2 is frustrating, and invariably ends up with a large number of customised rule configurations for any new static code analysis tool, or in fact ignoring the tool completely and marking it as worse than useless (which isn’t helpful either).
Other code analysis tools are available, like scrutinizr, PMD, etc ↩︎
You can argue this is a style thing; but this is absolutely a false positive. ↩︎
Pictures make people think you care about documentation!
What I’ve often noticed is that javadocs are kind of treated as a second class citizen when it comes a lot of opensource projects; not all projects, there are some with excellent javadocs; but, sadly, more often than not javadocs are an afterthought. Now, I’m as guilty as the next person for not having great javadocs; but you can spruce up your javadocs with some pretty UML diagrams courtesy of plantuml, graphviz and umldoclet…
Why not both, you shouldn’t have to choose; in this instance choice is useful
I try to be consistent in my development environments since they are spread across a number of platform: Windows, Linux and latterly Mac because McAfee sucked the performance out of my corporate issued laptop. I’m one of those odd people who happens to use all 3 major platforms actively for development. Scripts have always been bash, which means that I need to be able to run bash on my Windows systems; a long time ago it was Cygwin, but I found I didn’t need many of the features that it provided so I ended up using the bash that’s provided by Git for Windows; I have found that I need rsync to be available to make vagrant provision machines properly. I also like a bit of Windows subsystem for Linux so I have the choice of either installing my tools via scoop.sh or sudo apt-get. Sadly scoop hasn’t persuaded me that powershell is my goto shell.
Thinking pays off later; procrastination pays off right now…
Should you do it now or should you do it later? Strike while the iron’s hot or wait and see? In the context of development, this isn’t always an easy decision. You may not have the bandwidth or resources to finish that uber-feature right now when you have customers breathing down your neck about bugs that really should be classified as feature requests. You can opt to develop a solution that is tactical and not strategic; deferring those strategic decisions until some later time is a perfectly valid and meaningful form of planning. The biggest issue with deferring a decision is that circumstances can take the momentum away from you, and dictate any future path that you can take.
