What an excellent article. I'll share this with some of my team I think. Succinctly put, this embodies the requirement of software design for solutions that get off the ground and don't die 12 months down the road.
On our wall we have 10 commandments, the first of which is "Perfection is the enemy of good" - that pragmatism is vital, but also the need to have requirements your business user would never know - scalability, architectural design for the long haul.
I wrote some software in 1994 that was the core product of a data analytics software company. That design and architecture was still powering those businesses solutions up to 2017. The decisions we make early on are vital, if I'd got that totally wrong then that business would have either failed or had to replatform a lot earlier.
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
In my earlier career days I'd often struggled with orienting projects around whatever the new "it", or more conversely "right" way to do things was.
I'd get so trapped trying to make the solution work in that tiny box that by the time I was halfway through, the "right" way to do things would inevitably been thrown out and evolved into something else.
Eventually I needed to figure out for myself that my users ultimately didn't care as long as the thing worked.
Now, instead of designing specifically, I approach architecture to be as flexible and mutable as possible, while adhering to these pillars.
So far, it's worked out exceptionally well for my team. So we'll that I thought it was worth sharing here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What an excellent article. I'll share this with some of my team I think. Succinctly put, this embodies the requirement of software design for solutions that get off the ground and don't die 12 months down the road.
On our wall we have 10 commandments, the first of which is "Perfection is the enemy of good" - that pragmatism is vital, but also the need to have requirements your business user would never know - scalability, architectural design for the long haul.
I wrote some software in 1994 that was the core product of a data analytics software company. That design and architecture was still powering those businesses solutions up to 2017. The decisions we make early on are vital, if I'd got that totally wrong then that business would have either failed or had to replatform a lot earlier.
I appreciate the praise!
In my earlier career days I'd often struggled with orienting projects around whatever the new "it", or more conversely "right" way to do things was.
I'd get so trapped trying to make the solution work in that tiny box that by the time I was halfway through, the "right" way to do things would inevitably been thrown out and evolved into something else.
Eventually I needed to figure out for myself that my users ultimately didn't care as long as the thing worked.
Now, instead of designing specifically, I approach architecture to be as flexible and mutable as possible, while adhering to these pillars.
So far, it's worked out exceptionally well for my team. So we'll that I thought it was worth sharing here.