Advanced Ant Techniques

I wrote a two part series on advanced build scripting techniques using Ant in JavaRanch journal. You can read them here : Part One and Part Two

"Cost of ownership" What is our responsibility?

I was strolling down the aisles of a local home improvement store looking for a refrigerator. The price stickers on each appliance had a big yellow card next to them. It indicated the  yearly energy consumption on a low-medium-high scale and rated each piece on a 0-10 measure, 10 being the epitome of energyhungry-ness . I noticed the same on washer/dryers, cooking range and even water heaters.

The intent of the yellow sticker is to provide the buyers information about cost of ownership. Caveat Emptor - you not only pay for the appliance, you also pay a recurring cost to operate the equipment. What a novel idea!

Being an engineer at heart, I paused and chewed this idea for a while. Software systems today are no less commoditized than these appliances on the shop floor. Parallels can be drawn between the two, and factors that affect the cost of ownership identified.  

Requirements and design - Both are built to a design, and a set of requirements. - A missing requirement adds up to the cost of ownership by way of incurring cost of enhancements.  Similarly a bad design, or an inefficient design results in increased cost of ownership.

Use of non-standard technologies - Open and well accepted standards attract more buyers; products built on proprietary and  "home grown" standards  makes it harder to enhance it, fix it or to use it in conjunction with other similar products.

Build or Buy - Both can be either built from scratch versus assembled from pre-made components. Quality of a critical component, whether built or bought, has direct bearing on the cost of ownership. 

In fact, even the loss of productivity  adds up to the cost of ownership - for example, if your hard drive crashed, and you had to ship it off to the manufacturer, your cost of ownership just shot up by the order of magnitude of loss of productivity. How about fixing that Windows XP box so that you can use it ? And what about a poorly written installation guide for your spanking new wireless router that took away your entire Sunday afternoon?

 
 As developers, designers and architects, the decisions we make every day has a direct effect on the cost of ownership of whatever is that we are building. The choices we make, the compromises we settle for and even the processes we adopt for coding, reviewing and testing - everything affects the cost of ownership - increasing or decreasing the dollar value. Mostly because of the nature of software development, no predictable models exists that can accurately forecast the variations in cost of ownership based on dominant variables in every day Software Engineering - methods, tools, processes, technologies etc. Only our due diligence not just to the end product, but also to the means of building it can guarantee a minimal cost of ownership.

Thanks for reading!

Developer productivity - do you know yours?

Efficiency of execution is paramount to successful delivery. After months of planning, budgeting, staffing, tracking, preaching, and cheerleading, it all comes to execution. Execution is the most critical phase of SDLC when the folks in the trenches - the developers and testers, pickup the tools and start building the system, one block at a time. It is this phase that can make or break the project, and sadly, it is this phase that is often taken for granted.

Developer productivity is often a grossly glossed over aspect of many software development projects - both small and large. Few development managers realize that it is more important than anything else. While budget dollars are generously allocated for process improvement, requirement traceability, refactoring, business strategy planning and other grandiose exercises, very minimal, if any, time is spent on ensuring every developer working on the project has both the information and the tools required to complete the job. The result is obvious - tasks take longer, projects cost more and delivery slips.

Most if not all projects that either fail, or end up costing painfully more, or get miserably delayed are characterized lack of emphasis on developer productivity. It is not all done the moment you hire the brightest and the smartest; you still have to provide them with the tools and processes they need to get the job done. Nuances of software development makes this provisioning very tricky and unintuitive. Unlike other engineering methodologies that "build" something ( a bridge, a car or a house ) that are truly universally portable, the process of building software is neither universal or mechanical. Every company has a different process, every architecture is different and so are the tools. Organizations today take pride in individualizing the Software development processes, methodologies, tools and practices but fail to recognize that every such diversion from well-accepted( or the popular) industry standards actually proves detrimental to developer productivity.

Again, such deviations are not bad either. What is important though, is to help the new developers get through the learning curve as quickly as possible and get productive.
So what can you do to ensure soldiers have the ammo and drivers have the maps?

Measure and improve the average ramp up time for new team members.
Have the PMs track the pre-productive period for new hires. This can be easily achieved using a combination of project planning, allocation and diligent time reporting practices. Analyze the numbers and identify pain points such as - infrastructure issues, software issues, inaccurate documentation etc.

Publish documentation and make sure it is current.
Create a developer portal; but don't overload it with so much information that it becomes less inviting. Provide what is necessary and sufficient to get started. Constantly verify that the documentation is still valid and update when things change. The best time to do this is between iterations or milestones if you are following an iterative development methodology.

Provide automated build tools.
Reduce manual configuration steps and automate everything you can. This includes not only source builds, but mundane things like pulling code from CVS, setting up app server deployment scripts, and even validating if the dev environment is setup correctly. Often a 20 page 167 step documentation can be boiled down to a handful of batch files and greatly reduces the human error factor. Automated build tools can also verify that a piece of code being checked in is valid, and passes the unit tests - saving hours of "roll-back" time!

Educate, Emphasize and Enforce.
Conduct lunch-n-learns. Use open standards and best practices when possible. Use automated tools for checking code for consistency. Enforce standards through practical means such as peer reviews rather than "I agree" electronic signatures.

Focus on open standards to minimize the learning curve.
It never ceases to amaze me how many of my clients have "issues" with embracing open standards. If you must use a proprietary tool/technology stack, provide documentation, knowledge base and internal mentors. Do you have a "Getting started FAQ "? Getting the JSP guy to be productive on his first week is easier if you used Struts rather than, myCompanyPresentationFramework. Think about it.

Engage your IT folks
Do you ask the new hire to install WebLogic on the first day? Do you hav an Eclipse setup doc with screenshots of JRE preferences that need to be set? If every one in the development team uses the same set of tools( they better do!) and identical configuration, make a disk image so that use disk images.

Develop a knowledge base, a support community and a helper-buddy system.
Publish notes, tips, and nuances of your design/architecture. Make things such as Ports, connection strings, passwords, directory structures easily available. Saved "gold" configurations. Create SME contact list. Allocate a senior member on the team to help the new guy a few hours a week.

 Thanks for reading!