In enterprise software development with lots of money involved, it often ends up being poured into the following 3 categories:
- Business (business need, correctness of software in regard to business workflows)
- Quality (ease of maintainability, lack of bugs, need fewer developers)
- Speed (hire offshore, copy paste code, cut corners).
Success of the project is determined based on the share of each component. So what should be the right share? Let’s ask this question differently - if you could choose only one, which one would you choose?
Business people aka product owners will obviously choose business first. Because if the software doesn’t exactly do what business needs, then it’s useless, right? It depends.
Developers will generally prefer quality. It is exactly why they entered this field, in most cases. There are exceptions to the rule, and is generally related to habit, rather than innate motivation.
Managers or directors often take speed. More speed = less money spent = better. They also typically view software development as a kind of production line (think factory assembly where manual labour is involved), which is why 10 hour day is 25% more productive than 8 hours. To get more speed you simply hire more people, make existing people work overtime, have them take fewer breaks, you get the idea.
Taking a step back from code for a minute. Want to learn to play the piano fast? Learn it slow, then gradually speed up. Start fast - and you will fail, every time. There is no path from fast but incorrect notes to fast and correct. Even if you try many times, it will never work. Your brain needs time to process all these new inputs and rewire itself for new skills. For the record, I do play the piano and have tested this learning strategy in action.
But back to code. What happens if you choose business, and skip on quality and speed? You can potentially get a working piece of code that is 100% accurate, after a few years of development. Now wait until your requirement changes. It usually happens yesterday or a month ago. You need to rewrite the whole thing. Choosing speed is similar, except you need to rewrite it even faster. Best case you keep rewriting your code every 2-4 weeks, rinse and repeat. Yes, I have witnessed this happening on an actual project. Lots of stress and wasted effort.
Quality is everything. If there is one thing you could pick, it should be quality. And not simply because I am a software developer and was biased to pick quality. Quality code allows you to move fast. Quality code lets you adjust for new business need. In good hands, it is the foundation of any positive outcome.
You think that doing 8 hour workday in 1 hour is fast? Does it make you feel the smartest person in the room? What about doing 1 month of dev work in 1 hour? For that kind of productivity, it’s not enough to know your keyboard shortcuts, have a good IDE, fast development PC or laptop, SSD, cloud technology, or use docker. In modern day of 2020, it helps, but not a game changer anymore.
Instead, task your smart people with how they can get better every day at doing things they aren’t yet aware about. They gotta be going in a very particular direction without knowing that direction. How to prepare for the future (requirement)? Quality code. Follow the path of quality, and it will lead you towards the right answer. There were numerous times when I fixed all existing bugs related to a particular code piece by simply removing all nonsense from it. And they never came back.
So, quality is good, but should we produce it in scrum, Agile or waterfall methodology? Do we give our developers tasks, or do they take them? Should it be planning poker with fibonacci sequence estimate or T-shirt story sizes? Jira tickets or Gannt charts? Hire more managers of software development or directors of same?
Turns out simpler than that. Forget about points, sprints and all that jazz, let developers do their thing, and end up with 5 minute to bug fix time, and 1 hour for a feature. At that point, business can start moving in any direction it wants, faster than it was theoretically possible at inception. And you only need a handful of developers to make it happen. Oh and one thing - keep them happy, it can work wonders.
