"The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs."
Does failing the acceptance tests count as a "bug"?
Anti Mediocracy Manifesto for Software Development
81–90 of 110 posts
Re: Anti Mediocracy Manifesto for Software Development
#82Earlier quoted context omitted.
you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.
Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.
Sorry, I couldn't help myself :-)
http://e-venue.org/wp/ignore-the-real-world/
Re: Anti Mediocracy Manifesto for Software Development
#83> No, it's using tools to craft a work of art.
Stopped reading right there
Re: Anti Mediocracy Manifesto for Software Development
#84While very idealistic and beautiful in a way as all manifests tend to be, we (along the author) tend to forget certain truths - the middle of the gaussian curve is fattest; all natural distributions follow that curve, and developers are no exception. Most of us, by definition, are mediocre. There's nothing that can be done about it. We should not shun, but rather embrace that. Not by deluding ourselves that if we fol…
Being mediocre is a choice. It's the choice of the lazy and unemployed.
Re: Anti Mediocracy Manifesto for Software Development
#85> No, it's using tools to craft a work of art. Stopped reading right there
Then you did yourself a disservice, and now have trumpeted your laziness and ignorance.
Re: Anti Mediocracy Manifesto for Software Development
#86I personally don't think this is the correct way of looking at this situation.
Good code as it stands is code that produces an application that fulfills the requirements without breaking until someone naturally thinks to replace it. If you can achieve that you can achieve something better then most "good code" I've seen in my lifetime.
Good code is something that isn't obtrusive to the end user (the most important user of the code).
I don't know of another way of putting this but "easy to maintain" code is a different thing. Some small piece of software could have been messily globed together and thrown into production. This piece of software could have been running for 15 years+. I still think that's good code, but it is not inherently "easy to maintain."
We shouldn't be striving for 1 goal, we have two that are close to similarly important. We have maintainability by a programmer, and you have ease of use from the client.
To make the small fraction of people who are software devs live's better, we focus on "easy to maintain' code. To make everyone's life better we need to focus on that and making functionally sufficient code.
Very few projects I've seen do both. They either aim to be 100% clean code while sacrificing features that greatly improve UX or either 100% functional while being globed together unorganized messes.
I think we need to think of good code as a project that fulfills it's entire reason for existence while being documented and maintainable (on both the UX and maintaining side of things).
Re: Anti Mediocracy Manifesto for Software Development
#87Earlier quoted context omitted.
Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.
I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
And I disagree right back at you :)
All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements.
It's not "certainly less complex". The total complexity of the system is still the same.
Re: Anti Mediocracy Manifesto for Software Development
#88Earlier quoted context omitted.
It'd be kind of cool if you tried to improve your skill level, too. That is something you can do.
Of course I can and I do but the wider group will still always have a Gaussian distribution of skills more or less always. (as pointed out by parent comment)
Not usually......skill tends to have an exponential distribution, not a Gaussian distribution. Not everything falls into a Gaussian distribution.
Re: Anti Mediocracy Manifesto for Software Development
#89I could write a toughtful response to that... but given the quality of the original, this will suffice:
Eight
Be skeptical to any advice from a developer that is not old enough to have grown some white hair. If the advicer is male, gray beard preempts other white hair.
Nine
Be actively hostile to any advice by male developers that ar not old enough to have grown a beard at all.
Re: Anti Mediocracy Manifesto for Software Development
#90Earlier quoted context omitted.
I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is st…
And I... Kind of agree? :).
You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet.
>It's not "certainly less complex". The total complexity of the system is still the same.
The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze.
So, I assume that this something you agree with. In which case, congrats, you've convinced me.