- Kludge
-
noun • /klo͞oj/
• An ill-assorted collection of parts assembled to fufill a particular purpose.
• computing A machine, system, or program that has been badly put together.
Today I released my first application as a professional
developer. The product of 6 months of grinding to meet
deadlines, haggling with stakeholders, and more
setbacks than I care to think about at this moment.
I got it as a hand-me-down side project from a team that
clearly didn't have the bandwidth for it. It had no
documentation and no tests, which didn't matter because
it didn't work.
On the one hand, I got to learn frameworks I didn't
know. On the other hand, I had to use techs that I
wasn't comfortable with and that I wouldn't have chosen.
This is a story of failure. And victory. And of overcoming
circumstances out of my hands.
We don't always get to choose how we do things. We have
pressures from up the food chain. We have pressures to
use new technologies. We have pressures to meet
deadlines. When the deck is stacked against you, you
really have two choices. Do you get to work? Or do you
give up?
This was a learning opportunity. In more ways the one.
Sure I encountered tech I didn't know, but I'm talking
about more than collecting frameworks and learning
a cool new technique. I learned what not to do.
Never in my life would I want to build an application
like this again. I wouldn't wish it on my worst rival.
Everything that could go wrong went wrong.
I had to interface with existing procedures that were
out of my control and seemed tailored made to
antagonize my efforts. I had half enough time to finish
the product. There was a fundamental misunderstanding
of what it was I was even trying to build. When my
stakeholders and I finally got on the same page, they
changed the requirements. This was a crash-course
introduction to troubleshooting the process of software
development.
The end product certainly isn't perfect. There is less
code-coverage than I would have liked. There are almost
certainly bugs that will be discovered in the next month
of roll-outs. Certain functions take entirely too long
to finish, and unnecessary complexity is the standard;
not the exception.
I failed at designing an elegant system.
I failed at implementing that system smoothly.
I failed at planning.
I failed at testing.
I failed at being a professional engineer.
I had built a kludge.
However, I delivered a working piece of software that
accomplished the goals of the product owners. I
delivered it on time. In these two aspects, I succeded.
There is a story about a monk who lived in a monastery.
His first task at the monastery was to construct a brick
wall. Laying bricks is not easy. Keeping every brick
level and in line and straight and square is an almost
impossible task. Still, the monk tried his hardest
to make sure each brick was perfectly straight and
perfectly level.
After a long time, the monk had finished the wall and
felt a surge of pride. He had finished his wall. He
stood back, looked at what he had built and became
inconsolably distraught.
There were two bad bricks.
He had been so careful to lay each brick carefully so
that his wall would be perfect. The sight of those
two bricks ruined the whole wall.
So the monk goes to his superior and asks if he can
tear down the wall and start again. The elder monk
looked at the wall and said
Why would you want to do that?
and the monk responded
Can't you see the two bad bricks?
and the elder monk answered
Yes, I can. But I can also see 998 good bricks
Yes, I built a kludge. I wrote some unforgivably janky
code. And I assure you I would love nothing more than
to delete the whole project and start from scratch.
But I also know that there are 998 good bricks. I know
that it will function properly. And I know that this
application is what is needed by the people who wanted
it. They will might see the two bad bricks, and I
will try to learn from them and have my next project
be perfect. But they will also see 998 good bricks.
So I've decided to be proud of my kludge. At some point,
you will make a kludge too. At some point, we all will.
The important thing is that we don't let two bad bricks
spoil the whole wall.
Top comments (2)
@austinhardaway nice write up. It probably has happened to all of us at least in the beggining of our carreers that a project was not well defined and requirements kept on changing but we had to keep the course and deliver something useful despite of the mistakes/wrongdoing under the covers.
You should be proud of yourself that you kept this balance and came to the finish line. I have done it many times and it is really a pain and it is usually with companies/project that don't understand the nature of web dev and/or are on limited budget.
Perhaps you have to push back on some of those requirements and changes (on a future project) just to keep your sanity. The more you progress I guess you will learn in what circumstances you should fight back.
Cheers
Song on Spotify with the same title is worth a listen to! Keep up the learning and challenges