mark-995567_640

The software design is a difficult one for several reasons:

  • at the business level, is unheard of; the only elevated smells of it is performance and features, all others are too much details
  • most of the companies are started by entrepreneurs who have no idea what does it mean, in the rare cases when the technical geek is advancing a solution the managers are coming with the most dreadful imperative “please release it yesterday”
  • well, in the beginning the “time to market” or “first mover advantage” had so much priority that any glued-from-open-source-or-web-site solution was good
  • and only after the volumes pick-up you will feel the pain

We have been there by a “uninspired” chance and tried as much as possible to inject some order and process in the haste of “first-to-market” rush. And here is the recipe:

  • hire inexperienced people with touted experience and claimed “successful” projects
  • bring in people who have no idea what the industry is/was/will be and let them take “common-sense” business decisions
  • set the deadline and play by the ear of what is released or not
  • after the solution is released and the cracks show up, the masters of the solution jump ship
  • hire contractors and really check their references
  • don’t listen to the people who are taking the brunt of broken solutions and go with “fix it all along” piecemeal approach
  • postpone as long as you can version 2.0 because it is costly and you may repeat the problems from version 1.0
  • did you learn anything after looking at the living corpse of version 1.0 ?

 

Now, coming from a really successful project you might have some ideas on how to approach the uncharted territory:

  • read about the tools, libraries you want to use
  • create a map of the project and note what you want to achieve in terms of time, performance, extensibility, easiness to implement. Do you have the talent to pull it of (or have an idea if you can find it) and can estimate the cost ?
  • the architect should create a blue print and mock-ups. At this stage, you should test the most critical parts (or with a high grade of failure) like
    • can you support 10K concurrent users adding in the shopping carts
    • what kind of database model do you use, what ORM should employ
    • how do you measure the health of your application and of all adjacent services
    • you got my drift …
  • now, about the team, how do you control that herd of cats
    • are they comfortable and experienced to pull it off
    • AGILE anymore, but how
    • documentation or wiki
    • project management or project owners
    • CI or timed deliveries
    • do you have extra time/resources just to employ in case problems arise
    • how do you open visibility for the real shareholders
    • how do you communicate with the owner of the project and deviate from the specifications
  • if everything is working smoothly (rarely saw that in the four dimension of ANY software project – Schedule, Functionality, Cost and Quality) then you stepped up to the second level of the project – maturity and improvements

Will step in on each of the bullet lines mentioned here but this was a speed-dial and mockery of what software design and implementation is.