This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

390) Build a product where people can learn about and hear others empowered in their work and the fan following grows.

391) Build a product where they have to wait for orphaned resourcesn cleanup before they can proceed with re-install.

392) Build a product where the users have to frequently run the installer and it doesn’t complete some of the times

393) Build a product where the software is blamed because the administrator was shy to read the manual

394) Build a product where the resources for the software provided by the customer does not meet the requirements.

395) Build a product where different parts of the software need to be installed differently and find that deployments are usually haphazard

396) Build a product where the installation on production environment is so elaborate that it requires planning, dry runs and coordination across teams

397) Build a product where every update is used to justify setting aside a day by the staff

398) Build a product where the reality and perception are deliberately kept different at a customer site

399) Build a product where the vision for the product is different from what the customer wants to use it for.

400) Build  product where the quirkiness of the product offers fodder for all kind of talks from conferences to board room meetings.

401. Build a product where the last mile before the release usually requires everyone to pitch in 

402. Build a product where the pre-release efforts can never truly be separated from development efforts 

403. Build a product where the last mile gathers unwanted attention even though they don’t have any direct dependence on the product. 

404.  Build a product where the announcements become something to look forward to both for people building the product and those waiting for it outside. 

405. Build a product where the process of building never truly becomes a joyful process. 

406. Build a product where the release of a product is never really a starting point for the next version 

407. Build a product where the last few weeks for the release is usually reserved for making the customer experience better rather than during the development 

408. Build a product where the Murphy’s law seems to be more applicable towards the endgame 

409. Build a product where the week after the release still manages to throw surprises. 

410. Build a product where the customer celebrations of their success with the product adds joy to the work involved during development but the hands that made the product are no longer there.