IT Woes: Blown Deadlines.

Every IT Problem Is Technical

  1. Knowing what you are building — up to the littlest (technical) detail about the smallest part/module of your system.
  2. Knowing how you intend to build them: again, up to every little framework and API use. Only then you’ll know how long it’d take you.
  3. Confidence, that your team is as capable, as you are, so it’ll be a similar effort time/cost-wise compared to the ideal project staffed by experts like you.

Team Capabilities

Knowing What and How. “Architect’s” Responsibility?

Y2K Deadline: the Perfect Managerial Solution. Did It Work?

No “Architects” at Google

Case Study One: A Moderately-Scoped IT Project

Professional Atrophy

Trimming the Team

Technology

Getting Everyone Onboard

Case Study Two: SaaS MVP

Why Programming Takes So Damn Long?

  1. Invisible business plumbing: robust billing, DDoS protection, etc. addressing all catastrophic “what if” scenarios.
  2. Any record that can be created, can also be deleted. Users can make mistakes, that need to be “undone” (rolled back). E.g. any payment should be reversible. A customer can be given a credit for any reason. Oh, and both the initial action and the reversal need to be traceable via a detailed audit trail: 100% automatic in Px100.
  3. Tricky relationships between records. No, even a “relational” database is not going to take care of them automatically. Let’s say some record (account, deal, employee) is assigned to a specific user. What happens after deleting that user? Should all his/her records be reassigned? To whom? You need to explicitly ask the admin deleting the user, which means another UI screen backed by the server-side logic.
  4. Database “denormalization” for performance reasons e.g. displaying complex analytics and reports in real-time.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store