Let’s assume that you have a Samsung S6 phone and a Samsung TV and that you use videostream for example to see your pc videos on the tv. So since you want to change your tv source to use chromecast you download the samsung tv remote app (which could have been already installed on a samsung phone) so that you can do everything from your phone, select country and language, wait 10 minutes of download of you have no idea what and in the end …. no tv source change in the samsung tv remote app. But you can see the whole tv product set, ranging from 90″ curved screen to anything else … but no tv source change control …
Videostream guys, please put in your app a universal tv remote feature so that all operations on tv can be done from within the videostream app.
A growth in electric vehicles on European roads will need a corresponding growth in electricity production to serve charging of these cars, both in peak production power and in total annual power. Let’s take italy for example which currently has a total year consumption of around 300 TWh (terna). Considering :
This accounts for 2250 KWh/year for each electric car. Considering 2 milion new cars per year and a 0.5 % of electric cars sold (10000) this means an additional 22 GWh/year to be produced to allow charging them.
So your electric car will consume like a small household (depending on your mileage) and personal/distributed production of electricity (domestic + accumulation) will be necessary.
During one of my MTB rides at the Cancano lakes I stumbled into this beatifull dam which is part of the A2A Hydro power of Valtellina : 8 hydro power plants from cancano lakes down to Stazzona near Tirano using water coming from the Adda river and from other 4 different basins :
San Giacomo : 10MW
Braulio : 19 MW
Premadio : 226 MW
Grosio : 428 MW
Grosotto/Boscaccia : 13 MW
Lovero 49 MW
Stazzona : 30 MW
Adda river continues is ride down to Po river and in the mean time produces some other Hydro power in 4 hydro power plants that have been sold to EDF :
Over engineering code is a common plague that leads to a number of unwanted side effects in your software ranch. Consider it just a form of bad software design.
This post does not want to be an exhaustive guide on over engineering but with the help of many quotes from different sources, I’ll try to summarize the impacts, when you can have evidence of over engineered code and the causes (to try to avoid them).
Impacts
unneccessary complexity => less agility in software
more code, more bugs
more code, more unit tests, more development time
performance impacts
longer catch up time for newcomers
difficult maintenance, fixing bugs requires more time than it should
small changes require big efforts and are prone to having many bugs
unwanted features are present even though there is not reference in requirements/backlogs and so you have to maintain them even if they are not used
false perception of complexity in the code that leads to over inflated estimates for fixes, changes.
extending an over engineered project makes extensions more complex than necessary
dismantling of over engineered code takes way longer than it took to over engineer it
Need for complete rewrite over time to reduce unneeded complexity when maintenance times become higher than rewrite time This is an interesting topic itself and needs a separate post)
Concrete symptons of over engineered code
Really difficult here to point out some easy and simple guidelines to recognize over engineered code. Often it is an individual perception and this does not help. I’ll try :
When a well experienced coder, which has been working on that piece of code for at least an year, still takes way more than necessary/affordable to figure out where/how a specific feature works. I’m trying to find a better explanation for this concept
In code : using a factory even if it is making type of objects
In code : use an interface even if it is actually going to be implemented by just one class
“This is really going to be a clean framework. I’ll make an abstract class out of this part so that folks can subclass it later, and I’ll put in a bunch of well-commented overridable hooks in the concrete subclasses so that folks can use them as templates, and just in case somebody ever needs to build special debug subclasses, I’ll put in extra stubs over there (somebody will thank me for ’em one of these days). Yeah, this is really going to be neat.Thus is bloated software produced when our artistic sense gets the better of us. — DaveSmith “
Some other signs of over engineering taken from stackoverflow :
One very strong warning sign of over engineering is when everything goes through so much indirection that it’s hard to find the piece of code that actually implements some concrete, domain-level piece of functionality. If you find that most of your functions do very little concrete work and just call other virtual functions, you may have a problem.
[..] Make factories where the factories make more then one type of object. Use dependency injection, where it immediately shows benefits. Make interfaces that are actually going to be implemented by more then one class [..] What I see too often in “true OO” is that advanced techniques are used to solve really simple problems in an overly complex way [..]
Software should behave predictably and accomplish its goals without too many surprises (that is, outages in production). The number of surprises directly correlates with the amount of unnecessary complexity found in a project. It’s therefore crucial to think about accidental complexity and essential complexity:
Accidental complexity relates to problems which engineers create and can fix, [whereas] essential complexity is caused by the problem to be solved, and nothing can remove it — Fred Brooks in his seminal “No Silver Bullet” essay
Another interesting point on when a coder start to write unnecessary code :
Boredom is good precursor to over-engineered code. I’ll admit, when I got my first job, I felt so underutilized. I was just bored. And when I got bored, I wrote code. Not just any code — CATHEDRALS OF CODE.
No seriously, I had a mental picture of my code and abstractions as large towers with golden jutting spires, flying buttresses of glassy onyx, a wonderful vault supporting by arched domes topped with beautiful geometrical tracery, etc etc etc.
It was really fascinating to see the patterns working together for myself, but in retrospect, I am completely ashamed of the ungodly mess I left behind.
If you’re writing your own frameworks and DSLs code to while away the less stimulating hours at work, just stop. Time is better spent reading Wards Wiki, or writing an open source book, or you may just want to ask management for more work.
Some theory on why/when over engineering happens
Second system effect : you wrote a first good, simple, performant version of a product and it is getting traction so you decide to write 2.0 version of it which does everything.
feature creep : you just keep adding features that are used by less than 1 % of the user base/use cases.
inner-platform effect : you are making your system so customizable to become a replica of the features provided by the sw component of dev environment you are using.
I recently had a chance to try out SmartOS after my last experience in application porting on it (2012) and I was impressed by the virtualization features that are made available directly by the os. One set of commands allows downloading images, running either vm like container or namespace like containers. Zones also allow you to run debian/centos applications on SmartOS inside a lx zone with system call translation … Awesome.
If your interested in digging deeper take a look at this post from Tim Boudreau.
A growth in electric vehicles on European roads will need a corresponding growth in electricity production to serve charging of these cars, both in peak production power and in total annual power. Let’s take italy for example which currently has a total year consumption of around 300 TWh (
