I recently finished reading Applied Software Project Management by Andrew Stellman and Jennifer Greene. Stellman and Greene’s book has motivated me to read CMMI for Development, Version 1.2. Since CMMI is a model for process improvement, Stellman and Greene’s book has also encouraged me to get books on processes such as Rational Unified Process and Personal Software Process.
Stellman and Greene’s book makes the case for software engineering practices in a general way, leaving a reader wanting knowledge of specific practices that are used. Their book starts strong with their introduction of the Wideband Delphi estimation technique, which is one of a few specific practices that are discussed in the book. Their script for inspections is also strong, clearly stating the objective of inspections and how to run inspections efficiently. The strength of the book tapers off when discussing requirements acquisition, planning, design, and testing. Overall, Applied Software Project Management is a good introduction to the components of software project management. Other introductory books on software engineering practices claim that writing documentation before performing implementation is good, but Stellman and Greene’s book explicitly states why and how this is the case, and their book surely makes me more appreciate software engineering practices.
A local copy of CMMI for Development, Version 1.2 is found here.
The responsibility of a project’s outcome is shared between developers and managers. Developers depend on managers to effectively manage projects, and managers depend on developers to provide reports that serve as the basis of project management decisions.
Possibly due to insufficient transparency, a problem may be detected after attempting to use a fully implemented and unit-tested software component. The integration phase of a software life cycle is a common, but undesirable, phase to detect interface issues. The problem, found during the integration phase, potentially reopens tasks that were considered complete. Design documentation might need to be updated, software might need to be re-implemented, and software might need to be retested. This increases the difficulty of meeting a project schedule, which may already be tested during integration.
The person that detects the problem has the responsibility to make the problem known. Resolving the issue among developers of the affected modules may be possible, but in general, resolution will involve too many people and too many tasks. Utilizing the managerial structure is pragmatic and effective in coordinating a resolution. A line manager or immediate supervisor is an entry point of using the managerial structure, so reporting the problem to that manager is reasonable.
Without a problem report, management is unaware of the problem and unable to manage the project with respect to the problem. Reporting the problem to management is a practice that increases project visibility. Management may decide that the problem shall not be resolved, because of schedule pressure or the severity of the problem. Management may decide that it shall be resolved within the constraints of the project schedule. Management may also decide to resolve the issue and revise the project schedule. Management must make the decision for the project, but the need for a decision must be made visible by developers through problem reports.
I have just completed transitioning to a new server, which serves this blog. I am now using GoDaddy.com’s Virtual Dedicated Server product. I have been administering my own dedicated server, GoDaddy.com’s Dedicated Server product, for more than two years. I changed from a Dedicated Server to a Virtual Dedicated Server to reduce costs and better fit my utilization.
Though, I am not sure when the last time I rebooted my old dedicated server, the result of running ‘uptime’ on my old server is:
XX:XX:XX up 790 days, 15:23, X users, load average: X.XX, X.XX, X.XX
As I publish this post, the ‘uptime’ on my new server is:
XX:XX:XX up 2 days, 19:52, X users, load average: X.XX, X.XX, X.XX
I am still searching for tools that would allow me to do web development with Python. I was leaning toward Zope, but it looks like I will be going a different direction with WSGI. WSGI seems very lightweight or minimalist, which requires me to research template engines. Kubica’s HOWTO Use Python in the Web refers to Mako, Genshi, and Jinja. Mako looks like a good candidate.
When thinking about software modules as service providers and consumers, from time to time, a situation occurs where a service provider and a consumer communicate through a common or shared buffer. In the sockets API, the consumer of a service provides the buffers from which write() sends and to which recv() receives. This can be made to seem sensible, since these I/O functions can be seen as operating on arbitrary buffers. In this case, the buffers can be viewed as owned by or being more associated to the service consumers.
There are other situations where certain buffers are used only when communicating with specific service providers. When many such service providers with their associated buffers are present in a system, it is very possible that the buffers will be placed within a “buffers module,” or a module that consists entirely of buffers. This effectively disassociates the buffers from their respective service providers. Identifying the correct buffer that is dedicated to methods of a service providing module is more difficult, if that buffer is defined as part of another module as opposed to being defined within the module that is providing the service.
An increased risk of duplicate code is realized when buffers are placed in modules other than that of the consumers and providers. Implementers of service consumers may feel the need to independently implement functions to operate on these buffers. The duplication of code may be due to the lack of communication and coordination between the implementers, but this confusion could be minimized by recognizing the logical cohesion between the buffer and service provider, and placing the buffer within the module that outputs its results through said buffer. The service provider is also expected to implement functions that operate on its buffer. This localizes the functions that operate on the buffer to the service providing module, thereby reducing the risk of duplicate code among consumer modules with regard to the buffer and increasing cohesion between the buffer and the service providing module.